4 ms·
It is an application problem, agreed. It’s an application problem caused as a result of choosing the library, a common recommended library, and how the library
by tiew9Vii 2y ago
It is an application problem, agreed.
It’s an application problem caused as a result of choosing the library, a common recommended library, and how the library and its documentation promotes its usage. The tools used were as the tools recommend. Admittedly, joining the project the wrong tools for the job were selected but these are all the react standard supporting libs.
The application should have been architected not to use redux-query, instead use the browser fetchApi and server side cache control headers as we own the entire stack. Today that’s controversial as ”every body uses” and “this is what the docs recommends”
- hombre_fatal 2y agoWell, these libraries are doing something inherently complicated on top of just using browser cache headers. You're only talking about http endpoint caching. These solutions are providing application data caching. These are not mutually exclusive concepts. The latter offers things like data sharing/normalization across endpoints, data persistence across browser sessions, fine-grained cache invalidation/manipulation, and a lot of things on top of that. It's a lot harder to manage a cache, and for most apps I never found it worthwhile. But there may be cases where you do want that level of control, like PWAs or an app optimized to never hit the network unnecessarily. But it's definitely not replaceable with browser http header caching.