InertiaJS: Choosing Between Partial and Full Reloads for Shared Data

The Problem: Shared Data Updates Can Reset Client State

In an InertiaJS application, shared data is server-provided state available to every page component—things like the current user, notification count, permissions, or feature flags. When you refresh that data with a full reload, Inertia replaces the entire page payload and re-renders the component tree. Client-side state that is not stored in Inertia’s page data, such as an open modal, a draft comment, or scroll position, can be lost.

Useful takeaway: prefer Inertia.reload({ only: [...] }) for frequent updates to specific shared data, and reserve full reloads for navigation or structural layout changes.

Decision and Constraints

Choose a reload strategy based on what is changing and what must stay on screen.

• Constraint: the server-side Inertia adapter must support the only parameter. Official adapters exist for Laravel, Rails, Django, and Symfony, but older versions may ignore it.
• Constraint: partial reloads only filter shared data. They do not preserve form input state by itself; pair them with Inertia’s useForm or browser APIs if drafts must survive.
• Constraint: client adapters for React, Vue, and Svelte all expose the same reload behavior.

Supported Options: Partial Reload vs Full Reload

Option	What it refreshes	Client state impact	Typical payload	Best for
Partial reload	Only shared-data keys listed in only	Unrelated component state usually preserved	Smaller; contains only requested keys	Notification counters, permissions, user preferences
Full reload	All shared data and page props	Can reset modals, drafts, scroll position unless preserved	Larger; full page payload	Navigation, layout changes, authentication state changes

Trade-Offs

Partial reload

Advantages: less data over the network, unrelated UI stays intact, faster perceived update for small shared-data changes.

Disadvantages: requires backend cooperation to actually shrink the response; if the adapter serializes all shared data regardless of only, the network benefit disappears. It also does not touch non-shared page props or local component state.

Full reload

Advantages: simple and predictable; every component receives fresh props; no risk of stale shared data.

Disadvantages: higher payload cost and more chance of resetting ephemeral client UI state.

Implementation: Partial Reload for a Notification Counter

This example assumes a Vue 3 client and a Laravel backend, though the client call is identical across React, Vue, and Svelte adapters.

Client component

import { usePage } from '@inertiajs/vue3';
import { reload } from '@inertiajs/vue3';

export default {
  props: ['notifications'],
  setup(props) {
    const page = usePage();

    function refreshNotifications() {
      reload({
        only: ['notifications'],
        preserveState: true,
        preserveScroll: true,
      });
    }

    return { refreshNotifications, notificationCount: props.notifications.count };
  },
};

Call refreshNotifications on a timer or after a background event. The only array tells Inertia to request only the notifications shared-data key. preserveState and preserveScroll are Inertia options that help keep client component state and scroll position during the reload.

Server-side consideration

In Laravel, shared data is typically registered globally in a middleware or service provider. The Inertia Laravel adapter receives the only parameter and can limit the shared-data payload to those keys. Verify your adapter version before relying on smaller responses; if your backend always serializes every shared key, the client still receives a full payload even when only is sent.

Validate in Browser DevTools

1. Open the Network panel in Chrome, Firefox, or Edge.
2. Filter requests by XHR or fetch, or look for the Inertia page request.
3. Trigger the partial reload from the application.
4. Select the request and inspect the response body.
5. Confirm the response contains only the requested shared-data keys (for example, notifications) and not unrelated keys such as permissions or user unless they were also listed in only.

Run these steps in the browser as a user with normal access; no elevated permissions are required. If the response contains every shared key despite only: ['notifications'], your server adapter is not selectively filtering shared data, and the payload-size benefit is not realized.

Limitations

• Partial reloads do not preserve unsaved form input automatically. Use useForm or localStorage/sessionStorage if drafts must survive a reload.
• Behavior depends on the installed server adapter version. Older adapters may ignore or mishandle the only parameter.
• Non-shared page props are not affected by only; they are part of the page response and behave according to the full reload logic for that request.

Practical Check Before Deployment

Check the installed server adapter’s changelog or source for only or partial shared-data support. Then run the devtools validation above on a staging page. If the response matches the requested keys and an unrelated local counter does not reset during the reload, the partial reload is working as intended.