Before you read this article, I want you to know that it is a bit flawed, and I apologize for the mistakes I made previously, while authoring this ...
For further actions, you may consider blocking this person and/or reporting abuse
I feel like it doesn't really work, does it ? You're only waiting 5 arbitrary seconds and since the content of the page is not in the DOM it doesn't even fetch the images etc I believe ?
The way I did it was by using a loader that goes on top of the content instead of replacing it and listening to events from imagesloaded.desandro.com/ to know when the loader could be removed
Yeah Martin...
That was kinda like the idea around it... Some DOM contents (mostly images) takes time before they're displayed on a webpage.
The idea behind the usage of the
setTimeout
function is to show the leader for small amount of time instead of having a blank section that holds the image or content you're expecting to see on a webpage.I think, adding the preloading screen for a short amount of time helps to keep the users engaged on your website, before the contents of the page are fully ready.
One can also go ahead to increase or reduce the milliseconds. It all depends on your preferences, and the demography of the type of users your building for.
Yes I understood that, but the way you do it won't work I think, since NextJS won't load images that are not in the DOM, so you're making your users wait for nothing I believe ? The content to load should be in the DOM but you can show a loader OVER it while you're loading.
Example :
No Martin,
Nextjs already has it's own image optimization feature when they introduced the
<Image />
component.You can decide to pass properties like
onBlurdataURL
to display either a loader or masked image before the realy content is shown.But the aim of this article isn't related to that. Take for example, in some countries where the access to internet service is very poor. The time that it'll take toblaod some DOM elements will be high. A preloading component comes in handy in situations like this.
Yes, I know about the Image component but that doesn't have much to do with what I'm saying.
I don't think you understand what I'm trying to say but that's ok, my comments will be there to help people having trouble with it !
What will your own approach be like.
Can you share it with me? If you don't mind.
What the above commenters are saying is that your preloader isn’t actually preloading anything. It’s just waiting for a few arbitrary secs before showing the page. Assets may have loaded in less than that time, or some may have not fully loaded.
Page preloaders are generally based on a event listening to if all media has fully loaded (or completion of api request). You set an isLoading flag while your listener waits for all media to load fully, and once that’s true, isLoading can safely be set to false, so you can confidently show your page. This may take 1 sec, it may take 6 (hopefully not of course). The point is, you know for sure.
Sure 5 secs might seem like enough time for stuff to load, but you got other considerations - connection quality, device, image location/caching, etc. Conversely, your page might also be ready in 2 secs, and now your making the user wait for no reason (other than flourish).
This is more of a requirement with media and / or interaction heavy pages, where your experience requires everything is ready to ride 100%.
With Next, you’d bind that listener to useRouter’s events - routeChangeStart, routeChangeComplete.
Hope I explained that well?
Yes Stephen, you explained it absolutely well.
I also figured that adding the delay wasn't neccessary at all, and as you also said the page could be ready in 2 secs, and I'll be keeping the user waiting unnecessarily. Which would in turn account for a poor UX.
Thank you for your explanation. I'll make sure to add the changes in the article. 😎
i think you have misunderstood what Martin was saying. If you use conditional rendering, the page contents will be completely removed from the DOM during that 6s when loading was set to true. Which means no client side data fetching(in the page component you are hiding ofcourse), image loading etc running underneath. After 6s, loading is set to false, now the page goes to the DOM and then we will have to wait again for it to load.
Thank you for pointing this out too, Jun. 😎
I went through all the previous responses in this thread, and I was able to get the idea. I've made the correction in the article.
test reply.
Yes, Ivan. I'm setting the loader to be visible on every page render. That's why it is inside the
_app.js
file.And, yes... there's no logic that set's the loader back to
false
since we're making use of it in theuseEffect
hook, which runs only once, i.e. when the page is loaded for the first time or when it is refreshed.Hardcoding the loading time isn't the best way, it's false loading
Because In nextjs production things are very fast, user will be waiting unnecessarily for each page change
Instead you can use router events in nextjs
nextjs.org/docs/api-reference/next...
Hi @arshkkk ,
I'm not making the preloading screen show on each page change. Just when the page is first mounted to the DOM.
But, I'll definitely check the link you shared here. Thank you for sharing it 😎
Here's how I did this, rather than being an arbitrary load it actually does detect images being loaded.
Even this new solution not working. Your useEffect function should listen to router event changes and should look like this:
Thanks Ilir! Been learning about the super power of the
useRouter
hook lately. I'll have this modified to reflect the change as soon as possible.It's not actually a preloader. Preloader should have to wait till API will load, and some API's will take less time, some will take more, and using setTimeOut is actually making it static, but we need dynamic timing, which is not possible with your code.
I have problem in meta tags is not rendered when page is loading. Meta Tags will be should load in the request
Hi @abdulrahmanelheyb,
Kindly take a look at this article that explains a possible fix.