Allow progress bar to be disabled per request

[MarcEspiard]

Very simple change to allow users to disable the progress bar on a per request basis.

Seems like demand is fairly high from #124, and I've had the use case multiple times at work too.

Example use case, for a specific form submission (in our case, last step in our signup) we wanted to show a dedicated loading page and want to disable the top loading bar for that request only.
We've had other examples like reloading some props from a websocket event trigger etc..

[DominusKelvin]

I'll be overjoyed if this gets merged @reinink

Currently my own use case it's with the Hagfish invoice editor that partial saves as the user edits.

It makes an inertia put request and I'll be glad that my own loading feedback it's the only progress shown during those updates.

[peter-emad99]

it will make inertia very good when using it with ui optimistic updates...would love to see this pr merged very soon

[peter-emad99]

what is the current state of this small feature ? is it will be merged any time soon ?

[reinink]

what is the current state of this small feature ? is it will be merged any time soon ?

Hey! So long story short is that I haven't been totally convinced that this is the right decision from an architectural perspective. Inertia visits are synchronous, since they're meant to mimic classic page visits, and those always show progress.

However, I also understand why people want this feature — to disable the progress indicator for things like background polling requests and other more "async" style requests. However I'm not convinced that using Inertia visits for this is the right choice, at least right now. Here's why:

Since Inertia visits are synchronous, if a user clicks to visit one page, and then immediately clicks to visit a different page while the first request is still loading, the first visit is automatically cancelled and the second request takes over.

Meaning if you do an Inertia visit in some type of setInterval polling or websocket triggered reload you run the risk of visit stomping, where a user might click to go to another page and that request starts loading, but a polling/websocket reload happens to get fired right after and it cancels the user initiated page visit and the user is left wondering why their page didn't change.

Because of this challenge I've always recommended using fetch/xhr instead in these situations, since they can happen asynchronously in the background. The downside with that of course is that using Inertia.reload() is just so convenient and doing this manually with fetch/xhr requires a lot more wiring and even changes on the backend to accommodate a "plain" JSON response.

Because of all this I am actually planning to build some type of Inertia "async" visit feature that can be used for polling/background reloading that will 1) not cause "real" Inertia visits to be cancelled, and 2) will not show a progress indicator. This is high on our priority list 👍

That all said, I do think that this is a pretty compelling reason to still potentially offer a showProgress option:

Example use case, for a specific form submission (in our case, last step in our signup) we wanted to show a dedicated loading page and want to disable the top loading bar for that request only.

I hadn't considered that kind of use-case, and that's totally valid since there would still be a progress indicator shown to the user.

I think if we do introduce this option I'd like to do it at the same time as the async feature to make it clear what use-case each of these visit options is intended for 👍

[DominusKelvin]

what is the current state of this small feature ? is it will be merged any time soon ?

Hey! So long story short is that I haven't been totally convinced that this is the right decision from an architectural perspective. Inertia visits are synchronous, since they're meant to mimic classic page visits, and those always show progress.

However, I also understand why people want this feature — to disable the progress indicator for things like background polling requests and other more "async" style requests. However I'm not convinced that using Inertia visits for this is the right choice, at least right now. Here's why:

Since Inertia visits are synchronous, if a user clicks to visit one page, and then immediately clicks to visit a different page while the first request is still loading, the first visit is automatically cancelled and the second request takes over.

Meaning if you do an Inertia visit in some type of setInterval polling or websocket triggered reload you run the risk of visit stomping, where a user might click to go to another page and that request starts loading, but a polling/websocket reload happens to get fired right after and it cancels the user initiated page visit and the user is left wondering why their page didn't change.

Because of this challenge I've always recommended using fetch/xhr instead in these situations, since they can happen asynchronously in the background. The downside with that of course is that using Inertia.reload() is just so convenient and doing this manually with fetch/xhr requires a lot more wiring and even changes on the backend to accommodate a "plain" JSON response.

Because of all this I am actually planning to build some type of Inertia "async" visit feature that can be used for polling/background reloading that will 1) not cause "real" Inertia visits to be cancelled, and 2) will not show a progress indicator. This is high on our priority list 👍

That all said, I do think that this is a pretty compelling reason to still potentially offer a showProgress option:

Example use case, for a specific form submission (in our case, last step in our signup) we wanted to show a dedicated loading page and want to disable the top loading bar for that request only.

I hadn't considered that kind of use-case, and that's totally valid since there would still be a progress indicator shown to the user.

I think if we do introduce this option I'd like to do it at the same time as the async feature to make it clear what use-case each of these visit options is intended for 👍

That's cool @reinink. Inertia makes The Boring JavaScript Stack a possibility so I'm quite interested in seeing this land as well other async features Inertia plan on adding.

[peter-emad99]

Thanks @reinink for your detailed response , Inertia async visits will be great addition to inertia features and it will be very useful ,since it is essential requirement in any app today