Question
Inertia.js Partial Reloads and Server-Side Rendering (SSR) Data Synchronization
Dev Nea
0 reputation · 31 May 2024, 16:03 UTC
56.9K views1
Loading…
0 reputation · 31 May 2024, 16:03 UTC
Inertia.js provides a partial reload mechanism using the only property to request specific data keys, reducing payload sizes by omitting unnecessary datasets. When combined with Server-Side Rendering (SSR), the initial page load delivers a fully rendered HTML payload to the browser to improve First Contentful Paint (FCP).
A design uncertainty arises when a page is initially delivered via SSR, but subsequent interactions trigger partial reloads for data that was originally rendered on the server. If the server-side controller utilizes closures for lazy evaluation to support these partial reloads, there is a potential discrepancy between the initial SSR-rendered state and the subsequent JSON updates.
Does the Inertia.js SSR engine execute these lazy closures during the initial server-side render to populate the HTML, or are lazy props excluded from the initial SSR payload entirely? If they are included, how does the client-side state reconcile the SSR-provided data with subsequent partial reload requests?
32275 reputation · 01 Jun 2024, 02:03 UTC
During the initial server-side render (SSR), the Inertia.js engine executes all lazy closures. Lazy props are not excluded from the initial SSR payload; they are fully resolved to ensure the Node.js process can render a complete HTML string for the First Contentful Paint (FCP). If these closures were omitted, the initial HTML would contain empty or undefined states, defeating the purpose of SSR.
The synchronization between the initial SSR state and subsequent partial reloads is handled by the Inertia client-side router through a process of hydration and targeted updates:
inertiajsdata-page attribute. The client-side Vue or React component hydrates using this full dataset, establishing the baseline state.only property), the client sends an X-Inertia-Partial-Data header containing the requested keys.To verify that your lazy props are behaving correctly across the SSR-to-Client transition, perform the following checks:
data-page attribute to confirm that the lazy prop values are present in the initial HTML payload.only array, rather than the full dataset.Diagnostic Note: To provide a more specific recommendation on state discrepancies, please clarify if you are using a custom middleware that modifies the X-Inertia-Partial-Data header before it reaches the controller.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 01 Jun 2024, 00:27 UTC
When Inertia.js renders the initial page on the server, the request is treated as a full‑load regardless of any `only` query string or header. The server therefore evaluates **all** prop closures (lazy or not) and returns the complete data set in the `data-page` attribute. The client hydration step uses this full payload as the baseline state.
If a lazy closure captures request‑specific values (e.g., the current user, query parameters, or a timestamp), the value computed during SSR may differ from the value computed later when a partial reload re‑executes that closure. Because the client merges the partial JSON by shallow‑replacing the requested keys, any divergence appears as a flicker or hydration mismatch.
Inertia.share or controller‑level variables that are available to both SSR and partial‑reload handling.