6 ms·

For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for

For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with the built-in tools of React. And global state is only really an issue if it changes often. For mostly static state like information about the current user, theme or UI settings and similar kinds of state using React Context works perfectly fine. Of course this depends heavily on the kind of web application you write, if your application is closer to Photoshop in the browser than a simple CRUD app you probably can make good use of more complex state management libraries.

kasane 4y ago
This matches my experience as well. Additionally, React Query has support for features like retries and caching.
celim307 4y ago
React query is one of the highest quality react libraries I’ve ever used
bernawil 4y ago
The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient hah this is an understatement. For hooks, the React runtime already does a ton of non-standard-js things under the hood. useState gives a method to update and "subscribes" a component to updates on the hook's value. Put that code in a custom hook, export it and you re-invented Redux. In fact, exporting a single big useReducer for all your state gives you something almost identical to old style Redux.
- acemarke 4y ago
  FWIW, there _are_ a number of technical and conceptual differences between Context+`useReducer` and Redux. I wrote an extensive post describing those differences and potential use cases for each: https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
cercatrova 4y ago
Redux now has its own query solution as well, it's pretty useful [0]. [0] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview
cehrlich 4y ago
Agree completely, React Query has made it so much easier to build any kind of app that deals with server state, stuff that would have been extremely challenging to write in the past is now just a couple of lines and works better than before. I personally like using Jotai (if I just want a better version of React Context) or Zustand (if I need a bit more than that) for “client state” alongside React Query, but I’ve also built projects where I didn’t need a client state management solution at all.
- erikpukinskis 4y ago
  What’s wrong with React Context in your opinion?
  - cehrlich 4y ago
    For anything even slightly complex you need to either use multiple providers or be very careful about rerenders
ggregoire 4y ago
Exact same experience here. We were using Redux to manage server-side data and switching to React Query massively simplified everything. It appears that managing server-side data in an efficient way is an insanely complicated topic and React Query just solved everything about it that I can think of.
- acemarke 4y ago
  Yeah, both the React Query and Redux maintainers agree that you shouldn't be writing data fetching and caching logic yourself. That's why we recently added a new "RTK Query" data fetching and caching API to Redux Toolkit, so that if you're using Redux it handles that work for you: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview and if you're just using React, definitely look at React Query.
  - ggregoire 4y ago
    Yes we chose Redux 6 years ago for data fetching and caching when there wasn't as many alternatives as today!
    - acemarke 4y ago
      Hah, yeah, the ecosystem landscape has definitely changed over the last few years :)
  - buchanaf 4y ago
    RTKQ is terrific. Between things like that and MUI, the level of productivity you can achieve really is amazing. Also, thanks for your work -- really, really appreciate it.
likortera 4y ago
I've only used SWR. How does it compare? I
- krall12 4y ago
  SWR does basically the same core thing (query, cache and mutation help) with less features.
  - ospider 4y ago
    That's exactly the reason why I choose SWR over ReactQuery.
darepublic 4y ago
I took a look at react query and it seemed to me that the core of it was caching the network request promises with named keys, so that you could inefficiently call the same endpoint redundantly a bunch of times and not get punished for it. Even if a codebase could get away with such sloppiness it should probably avoid it. And then as I recall it featured some out of the box refetching to unstale the cached data. I think this core idea is pretty good, though I don't like the cultishness of the people who use this lib. And the vast majority of pages in the wild I have worked on don't need this auto-refresh, as the data will be static until the user does something new (i.e. because the user is viewing personal data). Even if I wanted to refresh the data often (i.e. I had a site like reddit) I would prob just roll my own custom refresh logic. And then this https://ui.dev/checkout/react-query?from=tanstack https://ui.dev/checkout/react-query?from=tanstack If server side logic is "insanely complicated", and is routinely being solved in two lines post react query, instantly working better than files worth of server side data fetching code, why the need to charge 149 to learn the fundamentals? If I had taken a paid course to learn a state management library I would probably advocate for it everywhere I went.
- blindmute 4y ago
  It's a great benefit for a component to be able to specify what data it needs from remote without worrying about if an ancestor or sibling also needed it. React query will only fetch once the unique queries in the whole tree. Without this feature, every component needing remote data D must share a parent ancestor fetching D for all of them, even when the children are not conceptually related. Adding another component higher in the tree means you have to hoist the fetcher up to that level, etc. React query is an incredible upgrade to anything else I've used over the years.
  - gofreddygo 4y ago
    > must share a parent ancestor fetching D for all of them What happened to the whole "service" pattern? Isn't this the core problem it solved for Java in the 90's?
    - 4y ago
lucasyvas 4y ago
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.
- code_biologist 4y ago
  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.
  - lucasyvas 4y ago
    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.
- gassiss 4y ago
  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

kasane 4y ago

This matches my experience as well. Additionally, React Query has support for features like retries and caching.

celim307 4y ago

React query is one of the highest quality react libraries I’ve ever used

bernawil 4y ago

The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient hah this is an understatement. For hooks, the React runtime already does a ton of non-standard-js things under the hood. useState gives a method to update and "subscribes" a component to updates on the hook's value. Put that code in a custom hook, export it and you re-invented Redux. In fact, exporting a single big useReducer for all your state gives you something almost identical to old style Redux.

acemarke 4y ago
FWIW, there _are_ a number of technical and conceptual differences between Context+`useReducer` and Redux. I wrote an extensive post describing those differences and potential use cases for each: https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

cercatrova 4y ago

Redux now has its own query solution as well, it's pretty useful [0]. [0] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview

cehrlich 4y ago

Agree completely, React Query has made it so much easier to build any kind of app that deals with server state, stuff that would have been extremely challenging to write in the past is now just a couple of lines and works better than before. I personally like using Jotai (if I just want a better version of React Context) or Zustand (if I need a bit more than that) for “client state” alongside React Query, but I’ve also built projects where I didn’t need a client state management solution at all.

erikpukinskis 4y ago
What’s wrong with React Context in your opinion?
- cehrlich 4y ago
  For anything even slightly complex you need to either use multiple providers or be very careful about rerenders

ggregoire 4y ago

Exact same experience here. We were using Redux to manage server-side data and switching to React Query massively simplified everything. It appears that managing server-side data in an efficient way is an insanely complicated topic and React Query just solved everything about it that I can think of.

acemarke 4y ago
Yeah, both the React Query and Redux maintainers agree that you shouldn't be writing data fetching and caching logic yourself. That's why we recently added a new "RTK Query" data fetching and caching API to Redux Toolkit, so that if you're using Redux it handles that work for you: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview and if you're just using React, definitely look at React Query.
- ggregoire 4y ago
  Yes we chose Redux 6 years ago for data fetching and caching when there wasn't as many alternatives as today!
  - acemarke 4y ago
    Hah, yeah, the ecosystem landscape has definitely changed over the last few years :)
- buchanaf 4y ago
  RTKQ is terrific. Between things like that and MUI, the level of productivity you can achieve really is amazing. Also, thanks for your work -- really, really appreciate it.

likortera 4y ago

I've only used SWR. How does it compare? I

krall12 4y ago
SWR does basically the same core thing (query, cache and mutation help) with less features.
- ospider 4y ago
  That's exactly the reason why I choose SWR over ReactQuery.

darepublic 4y ago

I took a look at react query and it seemed to me that the core of it was caching the network request promises with named keys, so that you could inefficiently call the same endpoint redundantly a bunch of times and not get punished for it. Even if a codebase could get away with such sloppiness it should probably avoid it. And then as I recall it featured some out of the box refetching to unstale the cached data. I think this core idea is pretty good, though I don't like the cultishness of the people who use this lib. And the vast majority of pages in the wild I have worked on don't need this auto-refresh, as the data will be static until the user does something new (i.e. because the user is viewing personal data). Even if I wanted to refresh the data often (i.e. I had a site like reddit) I would prob just roll my own custom refresh logic. And then this https://ui.dev/checkout/react-query?from=tanstack https://ui.dev/checkout/react-query?from=tanstack If server side logic is "insanely complicated", and is routinely being solved in two lines post react query, instantly working better than files worth of server side data fetching code, why the need to charge 149 to learn the fundamentals? If I had taken a paid course to learn a state management library I would probably advocate for it everywhere I went.

blindmute 4y ago
It's a great benefit for a component to be able to specify what data it needs from remote without worrying about if an ancestor or sibling also needed it. React query will only fetch once the unique queries in the whole tree. Without this feature, every component needing remote data D must share a parent ancestor fetching D for all of them, even when the children are not conceptually related. Adding another component higher in the tree means you have to hoist the fetcher up to that level, etc. React query is an incredible upgrade to anything else I've used over the years.
- gofreddygo 4y ago
  > must share a parent ancestor fetching D for all of them What happened to the whole "service" pattern? Isn't this the core problem it solved for Java in the 90's?
  - 4y ago

lucasyvas 4y ago

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.

code_biologist 4y ago
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.
- lucasyvas 4y ago
  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.
gassiss 4y ago
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