4 ms·
That sounds like absolute hell to dig through once you hit N+1 queries.
by eurasiantiger 3y ago
That sounds like absolute hell to dig through once you hit N+1 queries.
- bakugo 3y agoYeah, this is the kind of thing that seems elegant and convenient when the requirements are simple, but completely falls apart as soon as any complexity is involved.
- sli 3y agoThis tracks for me as well. Very quickly, you start having to manage 10, 15, 20, or more places where data in a store is being manipulated from outside the store and it quickly becomes unmanageable on anything beyond a toy-sized application. It almost feels like a rite of passage to decentralize like that and then start to pull back when it becomes a nightmare to debug and maintain.
- MrJohz 3y agoThat's the purpose of the in-app request caching layer. Another way to see it is that you do have state in a separate store, it's just that you have one piece of state for each resource that can be requested. So it's not that all the components are requesting the /users resource, it's more that all the components a requesting the value of the /users store, and the /users store fetches the data once and determines whether the data is loading, present, needs to be updated, etc.
- bayesian_horse 3y agoThat caching layer sounds like a footgun. RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.
- deleted 3y ago[deleted]