Using InertiaJS Partial Reloads to Keep Heavy Dashboards Responsive

The problem: full page visits waste bandwidth and UI state

Imagine a dashboard built with InertiaJS that shows a list of users, a chart of recent activity, and a sidebar with navigation. The user list can contain thousands of rows, making its payload large. When the user clicks a filter button, the typical Inertia approach is to call this.$inertia.visit('/users?filter=active'). This triggers a full page visit: the server returns props for all components (user list, chart, sidebar), the browser replaces the whole page state, and any local UI state (like a collapsed sidebar or a chart zoom level) is lost unless you manually preserve it.

If the only thing that changed is the user list, re‑sending the chart and sidebar data is unnecessary work. It also forces the browser to re‑mount those components, which can cause flicker or reset transient UI state.

Thesis: use the only option for targeted updates

InertiaJS v2 added a only option to the visit method. When you pass only: ['ComponentName'], the client asks the server to return props only for the named components. The server‑side adapter (Laravel, Rails, etc.) filters its response accordingly, and Inertia merges the returned props into the existing page state, leaving untouched components exactly as they were.

This achieves two goals:

1. Smaller network payload – only the data you need travels over the wire.
2. Preserved UI state – components not listed in only stay mounted, so scroll positions, form inputs, or chart interactions remain intact.

How to implement a partial reload

The pattern is the same for Vue or React; the example below uses Vue 3 with the Inertia plugin.

// Inside a Vue component (e.g., UserFilter.vue)
import { useInertia } from '@inertiajs/inertia-vue3'

export default {
  setup() {
    const { visit } = useInertia()

    const applyFilter = (status) => {
      // Request only the UserTable component; preserve scroll and other state
      visit(`/users?filter=${status}`, {
        only: ['UserTable'],          // ← component name as defined on the server
        preserveState: true,          // keep local component state (optional)
        preserveScroll: true          // keep scroll position
      })
    }

    return { applyFilter }
  }
}

On the server side (Laravel example), the controller does not need any special code; the official Laravel adapter automatically respects the only parameter when using Inertia v2:

// app/Http/Controllers/UserController.php
public function index(Request $request)
{
    $users = User::when($request->filled('filter'), fn($q) => $q->where('status', $request->filter))
                ->paginate(50)

    return Inertia::render('Users/Index', [
        'UserTable' => [
            'users' => $users->through(fn($u) => [
                'id' => $u->id,
                'name' => $u->name,
                'email' => $u->email,
                'status' => $u->status,
            ]),
            'filters' => request()->only('filter'),
        ],
        // Other components (Chart, Sidebar) are omitted when only=['UserTable']
        'ActivityChart' => [],   // empty array signals “skip” to the adapter
        'Sidebar' => [],
    ]);
}

When the only array contains 'UserTable', the Laravel adapter will serialize only the UserTable prop and send empty placeholders for the others, resulting in a much smaller JSON response.

Worked example: verifying the benefit

To see the difference in practice:

1. Open your browser’s developer tools and go to the Network tab.
2. Filter for XHR requests and trigger a full visit (e.g., by pressing F5 or visiting a new page).
3. Note the size of the response (look at the Size column).
4. Now click a filter button that calls the visit with only: ['UserTable'].
5. Observe the new XHR request; its payload should be noticeably smaller because the chart and sidebar data are omitted.

You can also inspect the response JSON: it will contain a UserTable object with the filtered users, while ActivityChart and Sidebar will appear as empty objects or be absent entirely, depending on the adapter’s implementation.

Trade‑offs and limitations

Partial reloads are powerful but not a silver bullet:

• Adapter support – The feature relies on the server‑side adapter to honor the only parameter. All official adapters (Laravel, Rails, Laravel‑like) support it from Inertia v2 onward, but custom or outdated adapters may ignore it and return full data, nullifying the benefit.
• Stale data risk – Components that are not included in the only array keep their previous props. If those components depend on data that can change elsewhere (e.g., a global notification count), you must manually refresh them or use a shared state solution (like a Vuex/Pinia store) to keep them in sync.
• Component naming coupling – The only value must match the exact key used when rendering the page on the server. Refactoring component names requires updating both client and server sides.

To mitigate stale data, consider combining partial reloads with occasional full visits (e.g., after a certain time interval) or using Inertia’s preserveState option to keep specific client‑side state while still updating the component’s props.

Actionable closing

If your InertiaJS page contains one or more data‑heavy components that update independently, start by identifying those components and giving them stable names in your render calls. Then replace full‑page visits with targeted visit calls that include the only array. Verify the improvement with the network tab, and monitor any components that rely on shared data to ensure they stay fresh.

By leveraging Inertia’s partial reloads, you reduce bandwidth usage, avoid unnecessary UI resets, and keep your application feeling snappy—even when dealing with large datasets.