Fallback to server navigation when fetching on the client navigation fails

[luisherranz]

I was thinking that, instead of figuring out how to report and deal with client-side navigation errors, the client router should just fall back to server-side navigation when something went wrong. As long as the HTML remains our API and the URL remains our source of truth, it should be simple and safe in 100% of the cases. So if something goes wrong again during the server navigation (maybe the user still doesn't have an Internet connection), the browser will show them the proper error.

Opinions?

[SantosGuillamot]

This totally makes sense to me 🙂 Would it make sense to make it optional somehow?

I'm thinking of a form doing a POST request. If I understood this correctly, if the server returns an error, it would load the gray screen with just messages like "Error: Please fill the required fields". I could imagine block developers wanting to handle those errors themselves and maybe create a new <div> in the HTML but keep showing the form. Whatever they want, basically.

[luisherranz]

Yes. I want to explore POST requests with @DAreRodz today, specifically for the Comments Form. I think those need to be some sort of controlled navigation requests, where the response is not displayed directly, but passed instead to a callback that can decide what to do.

[luisherranz]

Instead of this, in the end, we've made it possible to pass the html to navigate so that the fetch can be controlled by whoever calls the function.

[luisherranz]

We also need to add a timeout so if the navigate is taking longer than 30 seconds, assume something happened and fall back to server-side navigation.

[luisherranz]

I think we can close this one now. @DAreRodz opened a PR to add the timeout, and the navigate function already fall backs to the server-side navigation when something throws.

• Interactivity API: Add timeout option to navigate() #54474