Make the progress bar optional

[francoisauclair911]

Hi,
I know you guys are planing on adding more customization for the progress bar and I was wondering if it would be a good idea to make the progress bar optional on some requests

Proposition
Adding a showProgress props to the request and also inertia-link component
This props would be evaluated in the inertia.js and disable the progress bar if props is true

this.$inertia.post(url, data, {
  replace: false,
  preserveState: true,
  preserveScroll: false,
  only: [],
  showProgress: false,
})

<inertia-link href="/posts" showProgress="false" method="post">Save</inertia-link>

[francoisauclair911]

see PR #125

[reinink]

I'm curious, why would you want to disable the progress bar for specific requests? This seem unnecessary...but maybe I'm missing something?

[ShiferawAbel]

for example in your demo project in your website...there is a search inbox. And every time you type a letter it will send a request and ,ofcourse, show that progress bar every time you type a letter. Do you think that's necessary?

[geraldmacasaet]

Personally, I wouldn't want to send a request for every letter typed.

[reinink]

Closing this for now, because there hasn't been any other demand for this, and I don't really see the use-case myself.

@francoisauclair911 Feel free to provide your reasons, and we can always revisit.

[anubra266]

I actually think this is useful.
Use Case: I want to mark a notification as read, The user should not see a progress bar every time he clicks a notification, should he?
I found this thread while searching for a solution to this. Please implement it.

[reinink]

The user should not see a progress bar every time he clicks a notification, should he?

I kind of think the user should see a progress bar any time a request is occurring, and taking longer than the 250ms threshold, since with Inertia a synchronous page load is happening, and not just some "background" asynchronous xhr/fetch request that's clearing the notification. If you want the later behaviour, then I'm inclined to suggest just using xhr/fetch directly to do this, and not make an Inertia request.

[claudiodekker]

Hi @anubra266,

As of last month, the progress bar is an entirely separate package (https://github.com/inertiajs/progress) with a default (yet configurable) delay of 250ms. Since most simple requests finish between 60-120ms or so, we don't believe this should be a real issue for virtually anyone, unless they are on a very slow or unstable connection, in which case they might actually want to see a progress bar to indicate that something is happening.

That said, we're more than open to being proven wrong, so if you think we're mistaken or are missing something, please let us know by commenting on this issue, and we'd be more than happy to consider the situation and re-open this issue!

[anubra266]

If you want the later behaviour, then I'm inclined to suggest just using xhr/fetch directly to do this, and not make an Inertia request.

Regarding this, I just feel it'll be great to have Inertia cover most cases, as some of us - including me have decided that Inertia is my Primary Stack for all projects. Having to use Inertia, and still fallback to the old way in all my projects seems unneccessary.

Thanks @reinink

[reinink]

Having to use Inertia, and still fallback to the old way in all my projects seems unneccessary.

We get this more often, and I totally don't think this is the right way of looking at it. Rather, these are simply two different tools at your disposal. Use Inertia when making page visits, and use xhr/fetch when doing other asynchronous tasks.

It doesn't have to be one or the other. Both tools have their place...and I use both in my Inertia apps!

[reinink]

Fast Internet Connections is not a Luxury to me as a Developer.

And to be clear, I understand the not everyone has fast internet connections...which is arguably my point. Users should be aware that a slow request is still being sent...otherwise they could click on a different link and actually cause the "clear notification" request to get cancelled.

[anubra266]

Thanks @reinink
I'll take the manual xhr approach.

[reinink]

Reopening this issue, because there is other demand for it (#310, #311), plus, I'm starting to see a use-case for this for lazily evaluated props, that are loaded "in the background".

Inertia.reload({ only: ['something'], hideProgress: true })

[marc-firebrand]

Hey,

I'd love to see a way to disable the progress bar on demand.

Our use case is the following:
We have a real time dashboard displaying various pieces of data like user locations on a map, status counters, alert counters etc..
The dashboard (and any page in the app for that matter) has a websocket connection always opened with our backend.
On activity, status or alert update, the web app receives an even through websocket and has to refresh some props to keep the dashboard data live.
This can happen multiple times a minute so we use Inertia.reload({only: ['...']}); + lazy props to only refresh the required props.
As all our components use the props as their data source, everything works and is refreshed (this is why we love Inertia) without extra dev effort, it's very simple.
Given how often that happens we don't want to show a progress bar every time we refresh a counter or one marker on our map.
I do agree that most request will probably be under the delay threshold but we'd rather have actual control over it / disable it for people with slow connections or far from our hosting region.

Cheers

[adrianspacely]

Yes, same use-case here too. Second to that, I wish I could asynchronously request prop refreshes.

My problem is when you apply a filter to a dashboard widget, and then apply a filter to another widget, the first widget's request gets cancelled. I understand there is also a problem of how the URL changes only when the request finishes, but still.

To get around my problem, my filters component uses a single queue to wait its turn to set its query parameters in the URL.

[MarcelWeidum]

Is this already usable? I tried

setInterval(function() {
    Inertia.reload({ only: ['all_orders'], hideProgress: true })
}, 2500)

But it is still showing the progress

[anubra266]

@marc-firebrand checkout https://github.com/anubra266/vtril-progress

[sbc640964]

Reopening this issue, because there is other demand for it (#310, #311), plus, I'm starting to see a use-case for this for lazily evaluated props, that are loaded "in the background".

Inertia.reload({ only: ['something'], hideProgress: true })

What is really going on with this?
I encountered just such a case,
I have many widgets on the page, and I want to give a handle to each one so that it can only be refreshed, since the widgets are returned from inertia initially, I want to use only for this, the vanity of the progressbar bothers me.

[anubra266]

Oh thank you @reinink

[reinink]

To be clear though, all Inertia visits are still synchronous, so you can't use them for polling. See my comment here.

If you want async behaviour, then you need to use xhr/fetch.

[anubra266]

Ok... Understood

[goyote]

I'm guessing not support for:

        this.$inertia.put(route('users.preferences'), params, {
            hideProgress: true,
            showProgress: false,
        });

[anubra266]

Actually, that's what we're asking for

[goyote]

I ended up just using axios.post(route('users.preferences'), params); problem solved

[anubra266]

Cool!

[diego-lipinski-de-castro]

So, how can I do this nowadays?

[anubra266]

I use https://github.com/anubra266/vtril-progress

[mzabidin]

hi @anubra266 . i used vtril-progess as you recommended. it works well actually but however there is a case when i type fast in my livesearch box, the progress bar still shows up. But weirdly, when i type slowly, the progress bar doesn't show up. is there any way to fix that?

[sacsbrainz]

@reinink i think we as developers should have a little opinions too

Because right now am in need of such features for my Inertia.post method i don't need the progress bar showing

Not everyone likes the whole progress bar everywhere for everyone requests you maybe see it as unnecessary but then interiajs was build for everyone so maybe giving us some flexibility won't be a bad idea

Basically people use axios most times instead of the tools provided out of the box because of such little details

Also on a side note implementing infinite scroll with interia manual visits is not visible because of some issues, so i use axios and it all works for just saying thou

[marcus-m-hammer]

Here is my case. On data entry, I don't want the user to have click a save button, so I am saving each field onBlur. But for the case where the user decides to leave the page or refresh without leaving the current field, I use the on window.onbeforeunload to blur the activeElement. This works about 70% of the time. But, sometimes the refresh takes place before the data is able to save, thus losing data. So, I am faced with saving onChange vs onBlur. In this case, it would be great to have the option showProgress: false

Is there an alternative here that I haven't considered?

[anchan42]

I ran into this today. My use case is that I have a search box that would fetch suggestions from the backend based on user initial input. Something like Google search box. I managed to build a component that work using Inertia reload to load only the suggestions but having problem stop the progress bar from showing.

[marcus-m-hammer]

Other than turning the search bar off for the entire site, the only other option seams to be using axios. And, of course, here you loose a lot of the functionality that makes inertia so great. Someone please let me know if there is another option.

[DominusKelvin]

Okay I am co-signing this. I'm using Inertia in The Boring JavaScript Stack heavily and my latest project seems to need this.

I like the Inertia progress bar but my current implementation is saving the user editing their invoice on Hagfish as they type. Having to see a progress bar every time seems too much for that.

For this case @reinink i think we can let the burden of the progress be on the developers sometimes. For my invoice editor I do show feedback "Saving...", "Saved!"

I think that's enough feedback for the user.

Also when I use Lemon Squeezy which use Inertia, their UI show progress bar for almost all navigation including closing modals which I think it's superfluous.

I'd like to see this land in Inertia as I love this software and it's going to power how I build Fullstack JavaScript apps in The Boring JavaScript Stack

[damms005]

I'm curious as to why saving the edit state of an invoice is an Inertia request and not an async/xhr 🤔

[DominusKelvin]

I'm curious as to why saving the edit state of an invoice is an Inertia request and not an async/xhr 🤔

So the invoice is created with an Inertia post and I think it does make sense for an Inertia put to update it.

I know the argument is to drop down to XHR but I rather not as it works to use an Inertia put and then I can do only and use the form helper.

I try to use few XHR as for me Inertia shines for form submissions too.

[damms005]

Got you 👍

[IggsGrey]

My use case for hiding the progress indicator is in a music player app.

The external API i am using requires clients to poll an endpoint to see updated details like song names and cover arts for the now playing and history (previously played) sections.

I'm rendering the page with inertia - which passes the songs list (as a prop) to my react component.. I know I can setup an xhr call for this, but that means i have to set up a new state object to update anytime i make an xhr call (since I can't be updating the songs list prop from inertia). Now this means the song list prop from inertia would also be out of sync with the new state variable I create.

I'm not sure if it's a tedious task to hide the progress indicator but it'd be really easier for me if I could simply hideProgressIndicator: true in my inertia request not have to write new functions and state variables for an xhr call

[DominusKelvin]

My use case for hiding the progress indicator is in a music player app.

The external API i am using requires clients to poll an endpoint to see updated details like song names and cover arts for the now playing and history (previously played) sections.

I'm rendering the page with inertia - which passes the songs list (as a prop) to my react component.. I know I can setup an xhr call for this, but that means i have to set up a new state object to update anytime i make an xhr call (since I can't be updating the songs list prop from inertia). Now this means the song list prop from inertia would also be out of sync with the new state variable I create.

I'm not sure if it's a tedious task to hide the progress indicator but it'd be really easier for me if I could simply hideProgressIndicator: true in my inertia request not have to write new functions and state variables for an xhr call

Yeah this is valid.

[MarcEspiard]

Just submitted a PR for this #1842

Comments or upvotes on it might help get it merged

[DominusKelvin]

Just submitted a PR for this #1842

Comments or upvotes on it might help get it merged

Awesome I'll check it out!

[AnoNate]

@reinink I need the progress bar disabled because I have a function that has to clear all window timeouts. I guess the progress bar runs on a setTimeout ID, and I have no way of avoiding clearing that ID because I have no access to the id. So when I clear all window timeouts, the progress bar gets stuck and breaks my app.

I need an option to disable the progress bar OR a way to access the timeout id so as to not clear it in my clear all timeouts function.

[AnoNate]

I'm able to disable it in createInertiaApp by setting progress to false. Hope this helps anyone else using Inertia and React.

[IggsGrey]

Yes, it is possible to disable it globally, we're past that.

This issue thread is about disabling it on the fly for a specific request

[AnoNate]

Cool man, thanks for the lecture. I really appreciate the downvote too, even though my post may help someone. The title of this thread says nothing about specific requests, it just says "Make the progress bar optional", which it is. Next time I'll read the comments more thoroughly.