5 ms·

React is one tool for managing state. Still doesn't answer why

by throwadobe 2y ago

shadowgovt 2y ago
It's a good tool for managing state, especially state that, well, reacts to messages about changes in shared state.
- recursive 2y ago
  In react's model, all state is owned by a particular component instance. Most react devs opt for a 3rd party tool for shared state. I would not say that react is good at this.
  - bluefirebrand 2y ago
    This hasn't really been true for a while, most React projects that I encounter nowadays don't opt for things like Redux or MobX, they just use React Contexts. Which isn't a third party thing anymore
    - recursive 2y ago
      When context first came out, there was a buzz about it was going to obsolete Redux. Then it was actually "no it's not". I haven't followed it much since then. I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. But I guess it pretty much has to be an improvement over redux. Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
      - shadowgovt 2y ago
        > I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. I use this pattern commonly. You put a state-update callback into the context. It's my favorite go-to when I don't want to bother writing all that Redux boilerplate (state description plus accessors plus reducers feels... Half-baked).
        acemarke 2y ago
        Note that Redux usage patterns have changed significantly since 2019. Modern Redux with our official Redux Toolkit package is drastically simpler and easier to use than the original legacy hand-written patterns: - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today
      - acemarke 2y ago
        Hi, I'm a Redux maintainer. Context is not an "improvement" over Redux, because they are different tools with different purposes. (This is the primary misunderstanding people have when they try to compare Context and Redux.) Context is a Dependency Injection tool for a single value, used to avoid prop drilling. Redux is a tool for predictable global state management, with the state stored outside React. Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc). I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
        recursive 2y ago
        Thanks for the info. I'd say you're speaking from some position of authority about what redux is and isn't. And to some degree, what react context is and isn't. I vaguely recall seeing this blog post before, maybe. So redux is for "managing and updating" shared state. And context is for "sharing values". All this seems to suggest that react actually isn't that good at shared state, at least when it can change.
        acemarke 2y ago
        I'd both agree and disagree with that. React is based on the core concepts of encapsulated components, with the ability to manage state on a per-component-instance basis, and for parent components to pass _any_ values they want to their children as props, forming a "one-way data flow" approach. This is _good_, because it both enables predictable behavior and React's overall rendering model. It's _limiting_, because it means that React's own state management is inherently tree-shaped. If two widely separated components need to access the same data, you have to hoist the ownership of that state up to the nearest common ancestor, which could easily be the root `<App>` component. To put it another way, not all state is inherently tree-shaped, so there's often a mismatch. Context is essentially "props at a distance". Put a value in a `<MyContext.Provider>` component somewhere in your tree, then any deeply nested component can read it via `useContext(MyContext)` without having to explicitly pass the value as a prop through however many intervening levels of components. This simplifies making values accessible to that subtree, but doesn't solve the tree-vs-nontree-shaped state management question. You _can_ build an entire app out of nothing but React component state. Plenty of folks have done it, but it's limited in what tools you have available and how you can structure things. That's a large part of why there have been so many different state management libraries created for React, to provide alternative approaches that don't have the tree-shaped issue.

React is one tool for managing state. Still doesn't answer why

shadowgovt 2y ago

It's a good tool for managing state, especially state that, well, reacts to messages about changes in shared state.

recursive 2y ago
In react's model, all state is owned by a particular component instance. Most react devs opt for a 3rd party tool for shared state. I would not say that react is good at this.
- bluefirebrand 2y ago
  This hasn't really been true for a while, most React projects that I encounter nowadays don't opt for things like Redux or MobX, they just use React Contexts. Which isn't a third party thing anymore
  - recursive 2y ago
    When context first came out, there was a buzz about it was going to obsolete Redux. Then it was actually "no it's not". I haven't followed it much since then. I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. But I guess it pretty much has to be an improvement over redux. Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
    - shadowgovt 2y ago
      > I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. I use this pattern commonly. You put a state-update callback into the context. It's my favorite go-to when I don't want to bother writing all that Redux boilerplate (state description plus accessors plus reducers feels... Half-baked).
      - acemarke 2y ago
        Note that Redux usage patterns have changed significantly since 2019. Modern Redux with our official Redux Toolkit package is drastically simpler and easier to use than the original legacy hand-written patterns: - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today
    - acemarke 2y ago
      Hi, I'm a Redux maintainer. Context is not an "improvement" over Redux, because they are different tools with different purposes. (This is the primary misunderstanding people have when they try to compare Context and Redux.) Context is a Dependency Injection tool for a single value, used to avoid prop drilling. Redux is a tool for predictable global state management, with the state stored outside React. Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc). I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
      - recursive 2y ago
        Thanks for the info. I'd say you're speaking from some position of authority about what redux is and isn't. And to some degree, what react context is and isn't. I vaguely recall seeing this blog post before, maybe. So redux is for "managing and updating" shared state. And context is for "sharing values". All this seems to suggest that react actually isn't that good at shared state, at least when it can change.
        acemarke 2y ago
        I'd both agree and disagree with that. React is based on the core concepts of encapsulated components, with the ability to manage state on a per-component-instance basis, and for parent components to pass _any_ values they want to their children as props, forming a "one-way data flow" approach. This is _good_, because it both enables predictable behavior and React's overall rendering model. It's _limiting_, because it means that React's own state management is inherently tree-shaped. If two widely separated components need to access the same data, you have to hoist the ownership of that state up to the nearest common ancestor, which could easily be the root `<App>` component. To put it another way, not all state is inherently tree-shaped, so there's often a mismatch. Context is essentially "props at a distance". Put a value in a `<MyContext.Provider>` component somewhere in your tree, then any deeply nested component can read it via `useContext(MyContext)` without having to explicitly pass the value as a prop through however many intervening levels of components. This simplifies making values accessible to that subtree, but doesn't solve the tree-vs-nontree-shaped state management question. You _can_ build an entire app out of nothing but React component state. Plenty of folks have done it, but it's limited in what tools you have available and how you can structure things. That's a large part of why there have been so many different state management libraries created for React, to provide alternative approaches that don't have the tree-shaped issue.