I was wondering how to decide to use a route resolver to prefetch the required data for a given container (component). If, in my case, the API is slow, the UX will suffer from the slow response. The user will click the link, try to navigate to the route but the API call will still be active and the router will not resolve the route until the data has been fetched. Then, I can cache the data for subsequent route navigation.
But the main question/discussion here is when to use the resolver (the ideal situation) and when to avoid it so the user isn't waiting after the response. What is the best practice ?
asked Jan 4, 2018 at 16:01
IMO:
- Resolvers can be used for very tiny lite weight requests when you can be sure they will be processed quickly.
- But if you need to request some heavy information it is better to use ngOnInit with spinners or skeleton components (demo (click "Reload with ghosts")).
answered Jan 14, 2020 at 13:30
Comments
What is the best practice ?
It really depends on your app and its usage. On most desktop app, it really isn't necessary. I'd say the use case is for well thought UX.
A resolver is really useful for slow / mobile connections, It lets you gain a few ms. But if the request takes 3 seconds, a resolver won't be enough to calm your user, you need to go deeper and follow "reactive web app" principles and do things like display the "skeleton" of your component and then your data when loaded.
A resolver will add some performances to your app, but it won't be enough of it for really slow connections.
As when to avoid it, I don't really see a case were better performances will be bad. I guess sometimes the performances gain might not be really valuable and the time spent could be better use on something else.
answered Jan 5, 2018 at 12:26
4 Comments
Do you have any resources on the subject (for the reactive web app) part ? As for the moment, what I do is load the data on the ngOnInit method, show a spinner then remove the spinner when the data is loaded (the logical way).
@NicolasBoulet-Lavoie Here’s a medium article There’s a lot of sources out there, the issue being the ‘names’ associated with them. The core idea is to have better UX through a lot of fields (Design or Technical). For example, Google calls website that target mobile usage with a certain functionalities “Progressive Web App” here is a talk. But behind it, it’s just about improving UX for mobile use.
@NicolasBoulet-Lavoie On the technical side of things, there’s a lot a work around building responsive / reactive app. Things like redux have been build to handle complex UI through events. For more generality about reactive programming there is the Reactive Manifesto
Nice wrap up. Thanks.
You can get about 300ms head start by preloading data when the user hovers the link/button.
2 Comments
Interesting. But what if the user hovers the button by mistake (or just where the link goes) then the API call is fired back for nothing ? That's the edge case I see in this practice but I really think the idea is great. Have you implemented it in a particular application ? Have you tested the performance vs error gain ?
Interesting indeed - sadly flawed if touch is involved