9 ms·

React Common Tools and Practices: State Management Overview

51 points by debo_ 6y ago

throwanem 6y ago
Has anyone used XState here? What are its pros, cons, and gotchas? The idea of expressing application state as transitions in a state machine is appealing, and I'd be curious to know how others have found it as I consider trying it out for myself.
- Swizec 6y ago
  XState is fantastic for isolated pieces of complex state. Like a UI widget with action driven changes or a user’s auth state or a bells-and-whistles API request. But it’s not a replacement for state management as such. Here’s an example where I refactored a complex usereducer+context to xstate https://swizec.com/blog/react-context-without-context-using-xstate-codewithswiz-14-15 https://swizec.com/blog/react-context-without-context-using-...
- FpUser 6y ago
  I do not use React but I used concepts / implementations of state machines extensively in my native applications (GUI and backend)
- blktiger 6y ago
  I would say that using switching from Redux to XState is a bit like switching from js to typescript. You get additional rigor but that can of course slow you down and force you to deal with potential issues you might not have otherwise encountered. One of the nice benefits of XState is you can read the machine definition to easily understand how the state flows over time.
- fabian2k 6y ago
  I haven't used it in production yet, but I found it very interesting when experimenting with it a bit. One part I especially liked was how natural async actions work in XState. You can just insert a function that returns a Promise and define which state transition happens on resolve or reject. With other state management libraries or native react state management this ended up in ad-hoc state machines anyway. Though for pure server-side state I found React Query to be a pretty good solution that covers this part well. I'm not using it yet, but playing around with it did convince me that thinking in state machines or state charts is very helpful the moment the UI gets a bit more complex.
acemarke 6y ago
Oh hey, I literally just wrote this page yesterday :) For background, I've had to repeatedly spend time answering questions all over that really boil down to people not knowing what problems specific tools solve and when it _might_ make sense to use those tools (like, say, "Redux vs Context" [0]). The React team has kept the React docs and their advice focused on just using React itself, and avoided making recommendations or documenting tools and practices in the ecosystem. While they are in the middle of rewriting the React docs from scratch [1], as far as I know the new React docs still won't try to address things like "here's common tools in the ecosystem". So, I decided it was time to do something about this [2]. My goal is that this would be a moderately opinionated and curated site where people can see a list of tools and practices in various categories like "state management", "styling", "build tools", and so on, and read descriptions of "what is this tool, what problems does it solve, and when should I consider using it". I _don't_ want to turn it into arguments over "TOOL X IS BETTER THAN TOOL Y!". I _do_ want to get experts from the community involved in writing these pages, like having the maintainers of libraries like Mobx and XState write pages on when their own libraries should be used, as well as when it makes sense to use React component state instead. Yesterday I sat down for a few hours and hammered out a quick draft of the first couple pages for the site - this "State Management Overview" page, and a description of Redux and its use cases [3]. This is absolutely a first draft, and I hope to get the rest of the community involved in building this out! I just wanted to get _something_ written and live as a starting point for discussion and to kickstart the project. *edit* Okay, seriously, let me reiterate: THIS IS A FIRST DRAFT THAT I JUST THREW TOGETHER IN A FEW HOURS. I haven't even had a chance to go back and add more material to this "State Management Overview" page, like some of the info and resources I dug up yesterday [4]. That said, I _do_ want to get the React community involved in fleshing out the categories and material on this site! [0] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... [1] https://github.com/reactjs/reactjs.org/issues/3308 https://github.com/reactjs/reactjs.org/issues/3308 [2] https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1 https://github.com/markerikson/react-community-tools-practic... [3] https://react-community-tools-practices-cheatsheet.netlify.app/state-management/redux https://react-community-tools-practices-cheatsheet.netlify.a... [4] https://twitter.com/acemarke/status/1368716112469299200 https://twitter.com/acemarke/status/1368716112469299200
bredren 6y ago
Have you considered including React Query in your overview?
- acemarke 6y ago
  Yes, I intend the site to have an entire "Data Fetching and Caching" section that would cover things like: - Common tools for making AJAX calls (`fetch`, `axios`, self-written wrappers around `fetch`, and when to use any of those) - Info on things like REST and GraphQL as common backend API types - Libraries like React Query, SWR, Apollo, and Urql as common data fetching abstractions, and their use cases Tanner Linsley, author of React Query, has already said that he's happy to write a page on when it makes sense to use React Query [0] I suppose we'd probably want to end up having info on things like Firebase and Hasura too - maybe those would be better suited for a "Backends" section? Like I said in my sibling comment, right now I'm just trying to kickstart the idea of this site, get it off the ground, and get others in the community involved in making it a reality :) [0] https://twitter.com/tannerlinsley/status/1368600315432468482 https://twitter.com/tannerlinsley/status/1368600315432468482
  - DamodarSojka 6y ago
    If you will be including Hasura, please also don't forget postgraphile. - a fan of the project
- gpspake 6y ago
  Came here for this. When the author made me realize that a lot of our global state is just a client side cache of our server side state and we can apply a longstanding http caching standard (SWR) to manage it, it was as big of an aha moment for me as when I was originally introduced to redux. Speaking of redux, I'm a huge fan but React ships with a useReducer hook now - thanks in no small part, I'm sure, to the author of redux working on the react core team. These days, I'm all about reactQuery + react's native useReducer via the hooks and context api. described beautifully by Kent Dodds here: https://kentcdodds.com/blog/how-to-use-react-context-effectively#typescript--flow https://kentcdodds.com/blog/how-to-use-react-context-effecti... I feel like these state management libraries have largely served their purpose in establishing some agreed upon conventions that are now just baked in to React and other libs.
chmln 6y ago
Shameless plug: https://wire.js.org/ https://wire.js.org/ as an alternative focused on type safety and productivity.
- deleted 6y ago
  [deleted]
- phryneas 6y ago
  Shameless PR to update the "side-by-side" comparison on that page to an actually recommended style of Redux: https://github.com/wire-ts/wire-ts.github.io/pull/2 https://github.com/wire-ts/wire-ts.github.io/pull/2
IceHegel 6y ago
If any react noobs are reading this, the best React state management setup for you is Redux+Immer. After some setup, it's easy to use, and the docs are very good and up to date. When I was learning React, I kept putting off Redux because youtube said it was complicated and you didn't need it after useContext. Big mistake. Our app became more complicated because our state management(useState/useContext) was so simple. Switching to Redux dramatically simplified our most complicated components. Also, the Redux dev tools extension is a game changer. It lets you see every state change, in order, with traces and diffs. https://github.com/zalmoxisus/redux-devtools-extension https://github.com/zalmoxisus/redux-devtools-extension Pros can obviously make up their own mind. I’ve tried Mobx and the tooling just wasn’t there, but I hear their diffing algos are good.
- acemarke 6y ago
  To be clear, we now specifically teach that our official Redux Toolkit package is the standard approach for writing Redux logic [0]. RTK uses Immer internally by default [1], and I actually just wrote a brand new "Writing Reducers with Immer" usage guide page yesterday [2]. All that said, this new "React Community Tools" site isn't intended to specifically plug Redux or recommend it instead of other tools. I want it to be a catalog and informational site that helps people understand what tools are out there and what problems they solve, so that they can make decisions about what tools to use based on their own needs and applications. I just happened to write a Redux page first because that's what I know about, and I wanted at least one draft page up there so that we can nail down what some of the content structure for these pages should look like and use that as a basis for getting people to contribute pages for other tools. [0] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [1] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#immutable-updates-with-immer https://redux.js.org/tutorials/fundamentals/part-8-modern-re... [2] https://redux-toolkit.js.org/usage/immer-reducers https://redux-toolkit.js.org/usage/immer-reducers
- arvigeus 6y ago
  I managed to replicate Redux Toolkit api with context and hooks. Still, would not recommend it over Redux for performance reasons.
deleted 6y ago
[deleted]
decafbad 6y ago
I'd like to add Pullstate: https://lostpebble.github.io/pullstate/ https://lostpebble.github.io/pullstate/
brncsk 6y ago
Also see: https://recoiljs.org/ https://recoiljs.org/
CA0DA 6y ago
chrome giving me a "NET::ERR_CERT_AUTHORITY_INVALID" error ... anyone else?
bennettdams 6y ago
The combination of React's native context with hooks and realizing that a lot of your state is just "server cache" data (which can be handled "better" than using Redux) is probably enough for 95% of React applications. Kent C. Dodds has a great article covering both topics: https://kentcdodds.com/blog/application-state-management-with-react https://kentcdodds.com/blog/application-state-management-wit...
- phryneas 6y ago
  Just leaving Kent's more up-to-date opinion on modern Redux with the official redux toolkit here: https://youtu.be/xJpNIbJYK8Y?t=1523 https://youtu.be/xJpNIbJYK8Y?t=1523 You are right, if all your state is "cache state", then you don't need Redux. But at that point you don't need any state management library and are already searching for the wrong tool from the beginning. If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own though, both in developer experience as well as performance.
  - jeswin 6y ago
    > If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own Which you don't have to. React has been shipping useState, useContext, useReducer hooks for quite some time now - and will get you the exact same patterns seen in Redux (if so inclined).
    - acemarke 6y ago
      It's important to note that there _are_ differences in how `useContext+useReducer` behave vs how (React-)Redux works, especially around when and how components will re-render: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
ssijak 6y ago
Lately I use OvermindJS for state management in React. From devs perspective it is as simple as Mobx, but better, promotes nice separation of concerns and has good typescript support (improvers in the @next tag to be released soon) Redux has its uses but 95% of projects are better without it.
BenoitP 6y ago
This makes me think, with the arrival of continuous querying: * kSQL' EMIT CHANGES * Spark has stream-stream JOINs * Flink's default behavior ('time-varying relations') is to emit the changes * Materialize's value proposition is centered around event-streaming, and has Live Materialized Views. , is there a need for a client-side reactive SQL lib (react plugin?) where reactive data management would be done on continuous queries? If your client data is only a slice (CREATE VIEW slices AS SELECT .. JOIN .. ON .. = u.user_id [WHERE ..][GROUP BY ..]) of your server data, wouldn't it: * help a lot in cache management (as in: none to do. If you get reactive updates on changed data you don't need a cache) * help in moving client-side logic server-side, and vice versa (since it would be expressed in the same language) I mean: is there a market for it? Some people really do like SQL, I know I do.

51 points by debo_ 6y ago

Has anyone used XState here? What are its pros, cons, and gotchas? The idea of expressing application state as transitions in a state machine is appealing, and I'd be curious to know how others have found it as I consider trying it out for myself.

Swizec 6y ago
XState is fantastic for isolated pieces of complex state. Like a UI widget with action driven changes or a user’s auth state or a bells-and-whistles API request. But it’s not a replacement for state management as such. Here’s an example where I refactored a complex usereducer+context to xstate https://swizec.com/blog/react-context-without-context-using-xstate-codewithswiz-14-15 https://swizec.com/blog/react-context-without-context-using-...
FpUser 6y ago
I do not use React but I used concepts / implementations of state machines extensively in my native applications (GUI and backend)
blktiger 6y ago
I would say that using switching from Redux to XState is a bit like switching from js to typescript. You get additional rigor but that can of course slow you down and force you to deal with potential issues you might not have otherwise encountered. One of the nice benefits of XState is you can read the machine definition to easily understand how the state flows over time.
fabian2k 6y ago
I haven't used it in production yet, but I found it very interesting when experimenting with it a bit. One part I especially liked was how natural async actions work in XState. You can just insert a function that returns a Promise and define which state transition happens on resolve or reject. With other state management libraries or native react state management this ended up in ad-hoc state machines anyway. Though for pure server-side state I found React Query to be a pretty good solution that covers this part well. I'm not using it yet, but playing around with it did convince me that thinking in state machines or state charts is very helpful the moment the UI gets a bit more complex.

acemarke 6y ago

Oh hey, I literally just wrote this page yesterday :) For background, I've had to repeatedly spend time answering questions all over that really boil down to people not knowing what problems specific tools solve and when it _might_ make sense to use those tools (like, say, "Redux vs Context" [0]). The React team has kept the React docs and their advice focused on just using React itself, and avoided making recommendations or documenting tools and practices in the ecosystem. While they are in the middle of rewriting the React docs from scratch [1], as far as I know the new React docs still won't try to address things like "here's common tools in the ecosystem". So, I decided it was time to do something about this [2]. My goal is that this would be a moderately opinionated and curated site where people can see a list of tools and practices in various categories like "state management", "styling", "build tools", and so on, and read descriptions of "what is this tool, what problems does it solve, and when should I consider using it". I _don't_ want to turn it into arguments over "TOOL X IS BETTER THAN TOOL Y!". I _do_ want to get experts from the community involved in writing these pages, like having the maintainers of libraries like Mobx and XState write pages on when their own libraries should be used, as well as when it makes sense to use React component state instead. Yesterday I sat down for a few hours and hammered out a quick draft of the first couple pages for the site - this "State Management Overview" page, and a description of Redux and its use cases [3]. This is absolutely a first draft, and I hope to get the rest of the community involved in building this out! I just wanted to get _something_ written and live as a starting point for discussion and to kickstart the project. *edit* Okay, seriously, let me reiterate: THIS IS A FIRST DRAFT THAT I JUST THREW TOGETHER IN A FEW HOURS. I haven't even had a chance to go back and add more material to this "State Management Overview" page, like some of the info and resources I dug up yesterday [4]. That said, I _do_ want to get the React community involved in fleshing out the categories and material on this site! [0] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... [1] https://github.com/reactjs/reactjs.org/issues/3308 https://github.com/reactjs/reactjs.org/issues/3308 [2] https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1 https://github.com/markerikson/react-community-tools-practic... [3] https://react-community-tools-practices-cheatsheet.netlify.app/state-management/redux https://react-community-tools-practices-cheatsheet.netlify.a... [4] https://twitter.com/acemarke/status/1368716112469299200 https://twitter.com/acemarke/status/1368716112469299200

bredren 6y ago

Have you considered including React Query in your overview?

acemarke 6y ago
Yes, I intend the site to have an entire "Data Fetching and Caching" section that would cover things like: - Common tools for making AJAX calls (`fetch`, `axios`, self-written wrappers around `fetch`, and when to use any of those) - Info on things like REST and GraphQL as common backend API types - Libraries like React Query, SWR, Apollo, and Urql as common data fetching abstractions, and their use cases Tanner Linsley, author of React Query, has already said that he's happy to write a page on when it makes sense to use React Query [0] I suppose we'd probably want to end up having info on things like Firebase and Hasura too - maybe those would be better suited for a "Backends" section? Like I said in my sibling comment, right now I'm just trying to kickstart the idea of this site, get it off the ground, and get others in the community involved in making it a reality :) [0] https://twitter.com/tannerlinsley/status/1368600315432468482 https://twitter.com/tannerlinsley/status/1368600315432468482
- DamodarSojka 6y ago
  If you will be including Hasura, please also don't forget postgraphile. - a fan of the project
gpspake 6y ago
Came here for this. When the author made me realize that a lot of our global state is just a client side cache of our server side state and we can apply a longstanding http caching standard (SWR) to manage it, it was as big of an aha moment for me as when I was originally introduced to redux. Speaking of redux, I'm a huge fan but React ships with a useReducer hook now - thanks in no small part, I'm sure, to the author of redux working on the react core team. These days, I'm all about reactQuery + react's native useReducer via the hooks and context api. described beautifully by Kent Dodds here: https://kentcdodds.com/blog/how-to-use-react-context-effectively#typescript--flow https://kentcdodds.com/blog/how-to-use-react-context-effecti... I feel like these state management libraries have largely served their purpose in establishing some agreed upon conventions that are now just baked in to React and other libs.

chmln 6y ago

Shameless plug: https://wire.js.org/ https://wire.js.org/ as an alternative focused on type safety and productivity.

deleted 6y ago
[deleted]
phryneas 6y ago
Shameless PR to update the "side-by-side" comparison on that page to an actually recommended style of Redux: https://github.com/wire-ts/wire-ts.github.io/pull/2 https://github.com/wire-ts/wire-ts.github.io/pull/2

IceHegel 6y ago

If any react noobs are reading this, the best React state management setup for you is Redux+Immer. After some setup, it's easy to use, and the docs are very good and up to date. When I was learning React, I kept putting off Redux because youtube said it was complicated and you didn't need it after useContext. Big mistake. Our app became more complicated because our state management(useState/useContext) was so simple. Switching to Redux dramatically simplified our most complicated components. Also, the Redux dev tools extension is a game changer. It lets you see every state change, in order, with traces and diffs. https://github.com/zalmoxisus/redux-devtools-extension https://github.com/zalmoxisus/redux-devtools-extension Pros can obviously make up their own mind. I’ve tried Mobx and the tooling just wasn’t there, but I hear their diffing algos are good.

acemarke 6y ago
To be clear, we now specifically teach that our official Redux Toolkit package is the standard approach for writing Redux logic [0]. RTK uses Immer internally by default [1], and I actually just wrote a brand new "Writing Reducers with Immer" usage guide page yesterday [2]. All that said, this new "React Community Tools" site isn't intended to specifically plug Redux or recommend it instead of other tools. I want it to be a catalog and informational site that helps people understand what tools are out there and what problems they solve, so that they can make decisions about what tools to use based on their own needs and applications. I just happened to write a Redux page first because that's what I know about, and I wanted at least one draft page up there so that we can nail down what some of the content structure for these pages should look like and use that as a basis for getting people to contribute pages for other tools. [0] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [1] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#immutable-updates-with-immer https://redux.js.org/tutorials/fundamentals/part-8-modern-re... [2] https://redux-toolkit.js.org/usage/immer-reducers https://redux-toolkit.js.org/usage/immer-reducers
arvigeus 6y ago
I managed to replicate Redux Toolkit api with context and hooks. Still, would not recommend it over Redux for performance reasons.

deleted 6y ago

[deleted]

decafbad 6y ago

I'd like to add Pullstate: https://lostpebble.github.io/pullstate/ https://lostpebble.github.io/pullstate/

brncsk 6y ago

Also see: https://recoiljs.org/ https://recoiljs.org/

CA0DA 6y ago

chrome giving me a "NET::ERR_CERT_AUTHORITY_INVALID" error ... anyone else?

bennettdams 6y ago

The combination of React's native context with hooks and realizing that a lot of your state is just "server cache" data (which can be handled "better" than using Redux) is probably enough for 95% of React applications. Kent C. Dodds has a great article covering both topics: https://kentcdodds.com/blog/application-state-management-with-react https://kentcdodds.com/blog/application-state-management-wit...

phryneas 6y ago
Just leaving Kent's more up-to-date opinion on modern Redux with the official redux toolkit here: https://youtu.be/xJpNIbJYK8Y?t=1523 https://youtu.be/xJpNIbJYK8Y?t=1523 You are right, if all your state is "cache state", then you don't need Redux. But at that point you don't need any state management library and are already searching for the wrong tool from the beginning. If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own though, both in developer experience as well as performance.
- jeswin 6y ago
  > If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own Which you don't have to. React has been shipping useState, useContext, useReducer hooks for quite some time now - and will get you the exact same patterns seen in Redux (if so inclined).
  - acemarke 6y ago
    It's important to note that there _are_ differences in how `useContext+useReducer` behave vs how (React-)Redux works, especially around when and how components will re-render: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

ssijak 6y ago

Lately I use OvermindJS for state management in React. From devs perspective it is as simple as Mobx, but better, promotes nice separation of concerns and has good typescript support (improvers in the @next tag to be released soon) Redux has its uses but 95% of projects are better without it.

BenoitP 6y ago

This makes me think, with the arrival of continuous querying: * kSQL' EMIT CHANGES * Spark has stream-stream JOINs * Flink's default behavior ('time-varying relations') is to emit the changes * Materialize's value proposition is centered around event-streaming, and has Live Materialized Views. , is there a need for a client-side reactive SQL lib (react plugin?) where reactive data management would be done on continuous queries? If your client data is only a slice (CREATE VIEW slices AS SELECT .. JOIN .. ON .. = u.user_id [WHERE ..][GROUP BY ..]) of your server data, wouldn't it: * help a lot in cache management (as in: none to do. If you get reactive updates on changed data you don't need a cache) * help in moving client-side logic server-side, and vice versa (since it would be expressed in the same language) I mean: is there a market for it? Some people really do like SQL, I know I do.