[eurasiantiger]

That sounds like absolute hell to dig through once you hit N+1 queries.

[bakugo]

Yeah, 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]

This 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]

That'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]

That caching layer sounds like a footgun.

RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.