Comment by lucasyvas | Hacker News Reader

Comment by lucasyvas | Hacker News Reader

Parent Full thread

React Query's critical design flaw (from when I used it, anyway), is that data is scoped globally by default, as opposed to per mount.

Using the global cache is kind of the point, yes, but that's implicitly the case and that's the exact opposite of how useState works.

I think that is an egregious mistake, since it is totally unclear to a higher level consumer that this is the case.

This may seem unreasonable, but I've seen it cause severe issues due to this choice and I would recommend against it for many teams unless they can properly communicate that it does not match the behaviour of useState - you need to look through layers to be convinced it's going to do what you expect.

A simple flag to opt-in to the global cache associated to the provided key would solve a lot of problems.

To summarize, I like the API they provide a fair bit, but it's just too easy to misuse and create a damn mess.

data is scoped globally by default, as opposed to per mount.

Uh, is the cache key the same? To me it is 100% clear that the cache key is used for a global cache, and that this is one of the core design principles of the library. This global cache management is exactly what I desire over useState without writing my own boilerplate.

I personally liked the library for its query and mutation APIs, but would have preferred caching be left out or opt-in.

I ended up having to do this myself by wrapping it all up and providing an option for the caller to opt-in to the underlying global key. If the option was not passed, it would append a unique ID to the base key by default so it would become scoped to the particular mount.

IMO that should be the default behaviour.

Nothing implicit about react query caching requests. That's the whole point of the library in the first place, otherwise it would just be a fetch wrapper.

And having it behave differently from useState is fine, and correct. The library is used to fetch data, not state. Those are two different things

I disagree with the entire premise of the library then, because I consider a shared, global cache to introduce nothing but problems.

I like its query and request primitives, but I don't like that they are coupled to the cache.

It’s purpose in my mind is to model server state, which is fundamentally global state.

Are you using it for transient state? What are you using it for that’s meant to change between different parts of the app?

It kind of sounds like your namespace needs to be broader, are you using a singleton where a collection is needed?

Reply on news.ycombinator.com