Trigger the native browser loading indicator during page transitions
Unanswered
West African Crocodile posted this in #help-forum
West African CrocodileOP
Imagine I'm on /home and I open /posts. The posts page fetches data and the request takes 1 second. During this second, I have no visual feedback that something is loading, so my app looks frozen, and after 1 second the /posts page is displayed. I know I can add a loading.tsx file, but this will display a loader INSIDE the app. I would like instead to show a loading indicator at the browser level (which is for example a spinner around the favicon for Chrome, a blue loading bar at the bottom of the URL bar for Safari etc.) for the simple reason that this is what users are familiar with.
What I would like to achieve is exactly how nike.com navigation is on their website (they're using NextJS). If you're on the Nike home page and click on a product, the layout won't move, the page content will be injected in the layout, and in the meantime the browser shows a loading indicator.
I'm wondering how to achieve this
What I would like to achieve is exactly how nike.com navigation is on their website (they're using NextJS). If you're on the Nike home page and click on a product, the layout won't move, the page content will be injected in the layout, and in the meantime the browser shows a loading indicator.
I'm wondering how to achieve this
23 Replies
We use this for our wiki site, https://wiki.revivenode.com/
the blue loading bar at the top when you click on any links
the blue loading bar at the top when you click on any links
West African CrocodileOP
Sorry but this is not what my question is about, I said that I don't want a loading indicator inside the app, but at the browser level (the native loading indicator of your browser when you go from a page to another on traditional websites)
Yup, its better to handle it yourself. But if you want the browser to show when you go to a diff page it shld be the default, can you record changing pages without adding a loading.tsx
West African CrocodileOP
It is not the default, by default there is no loading indicator at all when you go to a different page, because NextJS does client side routing, and just fetches the new page and inject it in the layout, without refreshing the page, so by default there's no loading visual feedback to the user, and that's why loading.tsx is here. But I would like to use the native browser loading indicator instead of some component inside the layout
Check that out, dont use <Link>
you want something like that right?
@West African Crocodile It is not the default, by default there is no loading indicator at all when you go to a different page, because NextJS does client side routing, and just fetches the new page and inject it in the layout, without refreshing the page, so by default there's no loading visual feedback to the user, and that's why loading.tsx is here. But I would like to use the native browser loading indicator instead of some component inside the layout
a small fix with this, NextJS does client side routing its not NextJS which does it, its the <Link> tag which does client side navigation.
@Arinji https://4jfknt-3000.csb.app/
West African CrocodileOP
You're right, using a <a> tag instead of the <Link /> component does the trick, however I'm not sure if this is the best practice considering that you loose the prefetching benefits, and I'm not sure if this is what a website like nike.com does either 🤔
@James4u <@267198669911097345> why don't you try this?
https://www.npmjs.com/package/next-nprogress-bar
already suggested a similar one before, OP isnt looking for the same.
@West African Crocodile You're right, using a <a> tag instead of the <Link /> component does the trick, however I'm not sure if this is the best practice considering that you loose the prefetching benefits, and I'm not sure if this is what a website like nike.com does either 🤔
They probs do a similar thing of just using normal a tags. The entire idea is def not best practices. Ideally you handle all of the loading yourself with stuff i recomended, instead of using the browser.
But if you have to use the browser, use a tags
oh, as Next/Link does client side routing, that won't happen on the browser level
@West African Crocodile You're right, using a <a> tag instead of the <Link /> component does the trick, however I'm not sure if this is the best practice considering that you loose the prefetching benefits, and I'm not sure if this is what a website like nike.com does either 🤔
@West African Crocodile I don't think having loading spinner in the browser navigation bar is not a good idea - normally users don't care browser level navigation nowadays they usually try to find navigation (back or close) in the UI as well as the spinner.
That's why we are introducing spinners or loading skeletons - I think these are current UX
That's why we are introducing spinners or loading skeletons - I think these are current UX
West African CrocodileOP
I personally do think that a browser loader is a good idea since this is what users are used to. A client side navigation without browser loading feedback is kinda disruptive on normal websites (like Nike) that are not SPAs (like Spotify), and I think this is a reason why 99% of big websites DO still have loading at a browser level. And I don't think a website like nike.com is following NextJS bad practices. So I'm quite confused
@West African Crocodile I personally do think that a browser loader is a good idea since this is what users are used to. A client side navigation without browser loading feedback is kinda disruptive on normal websites (like Nike) that are not SPAs (like Spotify), and I think this is a reason why 99% of big websites DO still have loading at a browser level. And I don't think a website like nike.com is following NextJS bad practices. So I'm quite confused
most big sites, follow bad practices. Have you seen reddit?
@West African Crocodile You're right, using a <a> tag instead of the <Link /> component does the trick, however I'm not sure if this is the best practice considering that you loose the prefetching benefits, and I'm not sure if this is what a website like nike.com does either 🤔
yes it is the best method for you in this case. nike.com doesn't use <Link>, the layout staying in position is simply because the navbar is at the top and when you change the page, the navbar is still at the top.
@West African Crocodile I personally do think that a browser loader is a good idea since this is what users are used to. A client side navigation without browser loading feedback is kinda disruptive on normal websites (like Nike) that are not SPAs (like Spotify), and I think this is a reason why 99% of big websites DO still have loading at a browser level. And I don't think a website like nike.com is following NextJS bad practices. So I'm quite confused
nike.com is not a 100% nextjs website. they only use nextjs for part of the website, and the navbar is in fact not made with nextjs.
nextjs prefers a SPA-like behaviour, some other frameworks prefer a native browser-like behaviour (such as astro). both are good.
nextjs prefers a SPA-like behaviour, some other frameworks prefer a native browser-like behaviour (such as astro). both are good.
people have been using <a> for ages. there's nothing wrong with <a>.