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

[pedroborges]

I'm closing this PR since support for async requests is coming to v2.0 soon, as you can see in Taylor's Laracon keynote 🚀

[msurdi]

@pedroborges I've seen the beta for Inertia 2.0 has been released, but I'm still not clear how this can be achieved. Would you mind pointing me in the right direction?

Thanks!

[gabrielrbarbosa]

Also Inertia v2 wont support vue 2 right?

[pedroborges]

@msurdi the progress indicator options remain the same. As far as I know, the only difference is that now async requests don't show the progress indicator.

@gabrielrbarbosa correct 👍 Inertia 2.0 drops support for Vue 2 because it reached EOL last year.

[msurdi]

So can we reconsider this PR then? I think there is a valid use case where you want to submit a form and not show the global progress bar, for example if for a specific use case you want to show a local loading state.

[pedroborges]

@msurdi this PR is no longer needed, as the async option can now be used directly to control the progress indicator when making Inertia requests. Here's a quick example:

form.post('/user', { async: true })

While reviewing the code, I noticed a new showProgress option that’s not yet documented. This can be used on its own to disable the progress indicator:

form.post('/user', { showProgress: false })

This showProgress option is also helpful if you want to make an asynchronous request but still display the progress indicator:

form.post('/user', { async: true, showProgress: true })

[RobertBoes]

@pedroborges but that does work rather differently, right? An async request does not perform navigation, it cannot be cancelled by navigating somewhere else etc. Async has a specific use-case, that also happens to perform Inertia requests without the progress bar.

[pedroborges]

That's correct, thanks for the clarification @RobertBoes 👍

[msurdi]

Got it! Thanks a lot for the explanation.

[reinink]

Yeah, we added the showProgress option as part of v2 — this was useful for asynchronous visits, but you can also use this option to disable the progress bar for synchronous visits. We do think this is something that should be used carefully, but it is useful in the situation mentioned above:

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 need to get this added to the v2 docs still 👍

[pedroborges]

@reinink FYI, last week I opened a PR adding it to the docs 😉