Environment Details
- PHP Version: 8.3.29
- Laravel Version: 12.43.1
- Vue Version: 3.5.13
- Inertia.js Version: 2.x.x
- Inertia Modal Version: 0.21.1
Feture Request
Description
Provide a way to explicitly control how server-side redirect() responses affect the modal stack—allowing redirects to either stack, replace the current modal, or open as a fresh modal instead of always collapsing or navigating back to the base route.
Problem
When using nested modals with Inertia UI Modal, submitting a form via Inertia’s router (e.g. router.post() or useForm()) and returning a standard Laravel redirect() can cause:
-
the entire modal stack to close, or
-
navigation back to the base route,
-
loss of parent modal context.
This makes it difficult to implement common flows such as:
The current workaround is to use Axios for form submissions in nested modals, but this bypasses Inertia form helpers, validation handling, and consistent navigation semantics.
Expected / Desired Behavior
Allow developers to define how redirect responses should behave in the context of modals:
-
stack – open redirect destination as a new nested modal
-
replace – replace the current modal, keeping the parent modal open
-
fresh – clear the modal stack and open the redirect as a new root modal
(I think) This would enable standard Laravel + Inertia workflows without abandoning Inertia’s router.
Proposed API (examples)
Server-driven (header-based)
return redirect()
->route('users.edit', $user)
->withHeaders([
'X-InertiaUI-Modal-Redirect' => 'replace', // stack | replace | fresh
]);
Client-driven (router/form option)
if possible -
router.post(route('users.store'), data, {
modalRedirect: 'replace',
})
OR
form = useForm({
...,some fields
});
form.post(route('users.store'), {
modalRedirect: 'replace',
})
Modal-level default
<Modal redirect-mode="replace" />
It would be helpful to also have an option to use HeadlessModal alongside the existing modal implementation.
Example Use Case
- Open Users List in a modal
- Open Create User as a nested modal
- Submit form using router.post()
- Controller returns redirect()->route('users.edit', $user)
Expected (replace mode):
- Create modal closes
- Edit modal opens
- Users List modal remains open
Actual:
- Modal stack closes or navigates back to base route
Why This Should Be Supported Natively
- Redirect-after-POST is the standard Laravel pattern
- Modal stacking is already a core feature—redirect control is a natural extension
- Improves consistency, predictability, and DX for complex modal flows
Environment Details
Feture Request
Description
Provide a way to explicitly control how server-side redirect() responses affect the modal stack—allowing redirects to either stack, replace the current modal, or open as a fresh modal instead of always collapsing or navigating back to the base route.
Problem
When using nested modals with Inertia UI Modal, submitting a form via Inertia’s router (e.g. router.post() or useForm()) and returning a standard Laravel redirect() can cause:
the entire modal stack to close, or
navigation back to the base route,
loss of parent modal context.
This makes it difficult to implement common flows such as:
Create → Edit inside a modal stack
Multi-step modal forms
CRUD flows that rely on Laravel’s redirect-after-POST pattern
The current workaround is to use Axios for form submissions in nested modals, but this bypasses Inertia form helpers, validation handling, and consistent navigation semantics.
Expected / Desired Behavior
Allow developers to define how redirect responses should behave in the context of modals:
stack – open redirect destination as a new nested modal
replace – replace the current modal, keeping the parent modal open
fresh – clear the modal stack and open the redirect as a new root modal
(I think) This would enable standard Laravel + Inertia workflows without abandoning Inertia’s router.
Proposed API (examples)
Server-driven (header-based)
Client-driven (router/form option)
if possible -
OR
Modal-level default
It would be helpful to also have an option to use HeadlessModal alongside the existing modal implementation.
Example Use Case
Expected (replace mode):
Actual:
Why This Should Be Supported Natively