6 ms·
This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you ha
by wilde 4y ago
This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you have the genius idea to add optimistic updates in JS. Now you have all the problems from the article since you need to update all the components everywhere on screen that share state.
- petilon 4y agoAll you need is a client-side cache.
- wilde 4y agoHow do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux! (It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)
- petilon 4y ago> Your cache emits events that each UI element has to listen to? It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?
- ativzzz 4y agoIt's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change
- wilde 4y agoYeah this. The classic is unread state in a mail app. Unread state is usually displayed both as bold state per message in a message list, and as a count in the folder list. These need to stay in sync as the user reads mail (and sometimes marks read state explicitly). Two views of the same underlying state.
- petilon 4y agoSure, you can come up with an example where some synchronization is needed, but how often do you have this requirement? In most apps it is rare, which means that it can be solved by using a couple of extra lines of code to update the screen, as opposed to adopting a complex state management system with events firing and so on. Simple solutions for simple problems.
- wilde 4y agoIt is quite common. Take this screenshot of Youtube: https://imgur.com/a/nxGdcWj https://imgur.com/a/nxGdcWj The comments total at the top and each of the thread counts need to be kept in sync with their corresponding inline list representations. Most lists in apps display a total count summary. This is even more common on desktop, where you have room to display more info.
- lhnz 4y agoThat is exactly what the React state management solutions all are...
- pcthrowaway 4y ago> Now you have all the problems from the article since you need to update all the components everywhere on screen that share state. If anyone can field a question about react-query here, this seems like one of the exact problems I thought it solved when I started using it. I do enjoy using it, but requesting the same data with the same key+queryFn from multiple, unrelated components still generates regular requests at the configured interval (even if I'd want/expect those components to share the response and only make that request at whatever rate satisfies the shortest configured interval) Am I missing something in my configuration here?
- frosted-flakes 4y agoReact-Query is very aggressive about refreshing the cache by default, including whenever the browser receives focus, on a set schedule, and automatically retrying failed queries multiple times, these can all be disabled. If any queries use the same key they should share data, but I haven't experimented with it enough to learn all its intricacies.
- pcthrowaway 4y agoSure, all the other settings work fine (refresh on focus, failure retry, etc.), I just would have hoped to limit the requests made when the same data is requested in many different places.
- okhobb 4y agoTry checking out the options: refetchInterval: false, refetchOnMount: false, refetchOnWindowFocus: false, refetchOnReconnect: false, staleTime: Infinity, I was similarly surprised at how 'chatty' react-query was by default, but changing these defaults quieted it down. Great library though, and I understand the argument for these defaults.