Inertia.js shared data merge precedence during nested component rendering

Controller-level Inertia::share overwrites middleware for the same top-level key via a shallow merge

Confirmed fact: In the Laravel adapter, Inertia::share merges shared data with a shallow array_merge. The last call in the request wins for a given top-level key. Because middleware runs before the controller action, a key defined in middleware is replaced entirely if the same key is set later in the controller.

Order of precedence

Middleware share runs first, controller share runs second. The merge is shallow, not recursive. If both define 'user', the controller's value replaces the middleware's value. Nested properties from the middleware are lost unless manually preserved.

Deep merge support

Inertia.js does not provide a built-in deep merge for shared objects. The adapter replaces the whole value for a key. This is the likely explanation for unintentional data loss when a child component needs a modified version of a shared object.

Steps to retain parent state for this case

1. Read the existing shared value for the key during the same request.
2. Merge manually, then re-share.
3. Avoid re-using the same top-level key for child-specific additions; use a distinct sub-key when possible.

Example Laravel controller pattern:

$existing = session('inertia.shared.user', []);

Inertia::share(['user' => array_merge($existing, ['specific_permission' => 'value'])])

Assumption: Laravel adapter with session-backed shared storage. If you are using a different server-side adapter, verify its share implementation. Can you confirm which adapter you are using?