Add router configuration for displaying modal on non-Inertia responses

[Andy9822]

Description

This PR adds a new configuration option showModalOnNonInertiaResponse to the createInertiaApp function in all framework adapters (React, Vue, Svelte). This option allows developers to disable the automatic modal display when receiving non-Inertia responses and handle them in a custom way.

Problem

Currently, when a non-Inertia response is received (e.g., a regular JSON response instead of an Inertia response), Inertia automatically shows a modal with the response data. While this is helpful during development for debugging, it can create a poor user experience in production if not properly handled.

Proposed Solution

I've implemented this feature by adding a configuration option to the modal system. This approach aligns well with the existing architecture since the modal functionality is already encapsulated in its own module.

The implementation:

1. Adds a new ModalConfig type in packages/core/src/types.ts
2. Adds setupModal and getConfig methods to handle modal configuration
3. Modifies the modal behavior to respect the configuration setting
4. Adds the new option to all framework adapters' createInertiaApp functions

The modal configuration is set up during the client-side initialization in each framework adapter, ensuring consistent behavior across React, Vue, and Svelte.

Usage Example

createInertiaApp({
  resolve: (name) => import(`./Pages/${name}`),
  setup({ el, App, props }) {
    render(<App {...props} />, el)
  },
  showModalOnNonInertiaResponse: false, // Disable the modal
})

With this option disabled, developers can handle non-Inertia responses by listening to the inertia:invalid event:

document.addEventListener("inertia:invalid", (event) => {
  console.error('Received non-Inertia response:', event.detail.response)
  // Custom error handling logic
})

Benefits

1. Better Production UX: The automatic modal can be disruptive in production environments. This option allows developers to handle non-Inertia responses in a more user-friendly way.

2. Custom Error Handling: Developers can implement their own error handling logic based on their application's needs.

3. Maintains Development Experience: The modal is still shown by default, making it easy to debug during development.

4. Consistent Implementation: The configuration is handled uniformly across all framework adapters through the core modal module.

Additional Context

The modal error handling is very helpful during local development as it immediately shows what's wrong with the response. However, if this behavior accidentally makes it into production, it creates a very poor user experience. Users would see a technical error modal instead of a graceful error page or notification.

By providing this configuration option, we give developers the flexibility to handle these responses appropriately in their production environments while maintaining the helpful debugging experience during development.

Implementation Notes

The implementation uses the core modal module's configuration system rather than the router, which provides several advantages:

1. Direct control over the modal behavior where it's most relevant
2. Cleaner separation of concerns between routing and UI feedback
3. Simplified testing and maintenance since the configuration is closer to the feature it controls

The configuration is applied consistently across all framework adapters using the setupModal function from the core package, ensuring uniform behavior regardless of the framework being used.

Closes #2331

[Andy9822]

maybe this logic could be moved inside the modal.show so the caller doesn't need to know about this config or any business rule

[Andy9822]

Alternative Approach:

if we wanted to follow the same "API" used for the progress configs, we could instead have a modal = {} props and then call setupModal(modal)

[Andy9822]

A usage example of the alternative proposal would then look like:

createInertiaApp({
 modal: {
   showOnNonInertiaResponse: false
 },
 progress: { 
   delay: 300,
   color: '#29d'
 },
 resolve: (name) => import(`./Pages/${name}`),
 setup({ el, App, props }) {
   render(<App {...props} />, el)
 }
})

[Andy9822]

hey @joetannenbaum , do you have interest in this contribution?
I wonder if there's anything else I could add or adapt - if this looks like something you'd okay in merging

[pascalbaljet]

I think it's a good thing to have this option as this is the only place where Inertia is quite opinionated when it comes to UI. I'm not sure about the showModalOnNonInertiaResponse though. I opt for an errorModal key that defaults to true. That leaves the door open for a config object in the future.

Have you seen the documentation on handling errors in production? You can also redirect back (with a message) or render a dedicated error page: https://inertiajs.com/error-handling#production