3 ms·

The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I kno

The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. State management in React is a topic discussed to death, there are plenty of options if you have specific tastes or requirements but plain old React state works perfectly fine as well (especially when coupled to server-side state libraries like React Query). But Context is not about state management, it does not seem useful to complain that it doesn't do a job well it was never meant to do. The part about the Inspector component and the rules of hooks I don't understand. I would have put the visibility state outside the Inspector component, and then there is no need for any conditional calling of hooks.

lghh 4y ago
While I agree that the intent of Context isn't state management, but its functionality in practice is nearly identical to state management. I know and agree this has been discussed to death, so please be patient while I beat this long-dead horse. In the beta React docs, Context is described as: "Context lets the parent component make some information available to any component in the tree below it—no matter how deep—without passing it explicitly through props." [1] In the docs prior to that, they go over how to use the useState hook to manage state [2]. In the paragraphs immediatly following, they describe how to drill props to pass that state around to child components and how to lift it up so it is easier to share [3]. So, while Context may not explicitly be about state management, it's positioned as a way to make managing state via prop drilling much easier. It's easy to see how someone new to React would come to the conclusion that Context is about state management. The React beta docs all but say so. If the React team doesn't want developers to think about Context as state management, they should not implicitly position it as state management. [1] - https://beta.reactjs.org/learn/passing-data-deeply-with-context https://beta.reactjs.org/learn/passing-data-deeply-with-cont... [2] - https://beta.reactjs.org/learn#updating-the-screen https://beta.reactjs.org/learn#updating-the-screen [3] - https://beta.reactjs.org/learn#sharing-data-between-components https://beta.reactjs.org/learn#sharing-data-between-componen...
- fabian2k 4y ago
  Context is useful for certain cases, but plain old useState/useReducers are the workhorses. I think the beta docs are pretty good about explaining the tradeoffs (https://beta.reactjs.org/learn/passing-data-deeply-with-context#before-you-use-context https://beta.reactjs.org/learn/passing-data-deeply-with-cont...). To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many applications. With hooks we don't have deeply nested Higher-Order components anymore, if you pay a bit of attention you can have reasonably shallow component hierarchies and props work very nicely then. Server-side state is a special case, I find that much easier to handle with something like React Query. But once that is done I don't see much need for any external state management library like Redux, useState/useReducer works pretty well. And yes, sometimes Context is useful for state that doesn't change much. But those are the cases where the drawbacks don't matter. But that is a special case, not necessary for the vast majority of state.
  - bluefirebrand 4y ago
    > To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Prop Drilling is considered an anti-pattern for good reason. It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set. Keeping that clean is one of the most important things you can do in a frontend codebase imo.
    - fabian2k 4y ago
      That doesn't make sense, props are easily to follow and they only flow in one direction from parent to children. Excessively deep component structures are a problem, but not only because of the excessive prop drilling they cause.
      - the_gipsy 4y ago
        Except when props are callbacks, e.g. probably a useState combo.
scrozier 4y ago
This conflation of Redux and Context as state management is devilishly persistent. As I see it, Redux is [state management] + [prop passing], and Context is [prop passing]. There is no [state management] "feature" of Context. You still have to use (something like) useState for [state management] with Context. As long as people try to compare them as equivalent feature sets, the confusion will continue.
acemarke 4y ago
Yep. The article has some good points overall, but Context was definitely never intended as a replacement for Redux. Redux and Context are different tools that solve different problems, with some small overlap. Honestly, this is a point of confusion I see folks ask about _every_ day. 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 ended up writing 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: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
suzzer99 4y ago
Yeah this. We use Context to apply different themes in a multi-tenant app, and we use Redux to manage global state like the header. Both are great for their purpose.
epidemian 4y ago
> [React Context] was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. I think the conflation came more from the "community" than from the React team itself. Many people were (ab)using Redux for simple cases were Context would have been sufficient and, in the process, paying the price of having a lot of boilerplate related to writing anemic "reducers" whose only purpose was to store things on the global state, and eventually also paying the price of having a ball-of-mud of a global state where no-one could be sure of the dependencies between components, as anyone could be accessing anything on that big ball-of-mud. (Been there; not proud.) So, when the Context API came along, with a much leaner API (no actions or reducers) and less "global-y" feel than Redux, people who were misusing the latter naturally saw the former as a good replacement

lghh 4y ago

While I agree that the intent of Context isn't state management, but its functionality in practice is nearly identical to state management. I know and agree this has been discussed to death, so please be patient while I beat this long-dead horse. In the beta React docs, Context is described as: "Context lets the parent component make some information available to any component in the tree below it—no matter how deep—without passing it explicitly through props." [1] In the docs prior to that, they go over how to use the useState hook to manage state [2]. In the paragraphs immediatly following, they describe how to drill props to pass that state around to child components and how to lift it up so it is easier to share [3]. So, while Context may not explicitly be about state management, it's positioned as a way to make managing state via prop drilling much easier. It's easy to see how someone new to React would come to the conclusion that Context is about state management. The React beta docs all but say so. If the React team doesn't want developers to think about Context as state management, they should not implicitly position it as state management. [1] - https://beta.reactjs.org/learn/passing-data-deeply-with-context https://beta.reactjs.org/learn/passing-data-deeply-with-cont... [2] - https://beta.reactjs.org/learn#updating-the-screen https://beta.reactjs.org/learn#updating-the-screen [3] - https://beta.reactjs.org/learn#sharing-data-between-components https://beta.reactjs.org/learn#sharing-data-between-componen...

fabian2k 4y ago
Context is useful for certain cases, but plain old useState/useReducers are the workhorses. I think the beta docs are pretty good about explaining the tradeoffs (https://beta.reactjs.org/learn/passing-data-deeply-with-context#before-you-use-context https://beta.reactjs.org/learn/passing-data-deeply-with-cont...). To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many applications. With hooks we don't have deeply nested Higher-Order components anymore, if you pay a bit of attention you can have reasonably shallow component hierarchies and props work very nicely then. Server-side state is a special case, I find that much easier to handle with something like React Query. But once that is done I don't see much need for any external state management library like Redux, useState/useReducer works pretty well. And yes, sometimes Context is useful for state that doesn't change much. But those are the cases where the drawbacks don't matter. But that is a special case, not necessary for the vast majority of state.
- bluefirebrand 4y ago
  > To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Prop Drilling is considered an anti-pattern for good reason. It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set. Keeping that clean is one of the most important things you can do in a frontend codebase imo.
  - fabian2k 4y ago
    That doesn't make sense, props are easily to follow and they only flow in one direction from parent to children. Excessively deep component structures are a problem, but not only because of the excessive prop drilling they cause.
    - the_gipsy 4y ago
      Except when props are callbacks, e.g. probably a useState combo.

scrozier 4y ago

This conflation of Redux and Context as state management is devilishly persistent. As I see it, Redux is [state management] + [prop passing], and Context is [prop passing]. There is no [state management] "feature" of Context. You still have to use (something like) useState for [state management] with Context. As long as people try to compare them as equivalent feature sets, the confusion will continue.

acemarke 4y ago

Yep. The article has some good points overall, but Context was definitely never intended as a replacement for Redux. Redux and Context are different tools that solve different problems, with some small overlap. Honestly, this is a point of confusion I see folks ask about _every_ day. 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 ended up writing 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: - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

suzzer99 4y ago

Yeah this. We use Context to apply different themes in a multi-tenant app, and we use Redux to manage global state like the header. Both are great for their purpose.

epidemian 4y ago

> [React Context] was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. I think the conflation came more from the "community" than from the React team itself. Many people were (ab)using Redux for simple cases were Context would have been sufficient and, in the process, paying the price of having a lot of boilerplate related to writing anemic "reducers" whose only purpose was to store things on the global state, and eventually also paying the price of having a ball-of-mud of a global state where no-one could be sure of the dependencies between components, as anyone could be accessing anything on that big ball-of-mud. (Been there; not proud.) So, when the Context API came along, with a much leaner API (no actions or reducers) and less "global-y" feel than Redux, people who were misusing the latter naturally saw the former as a good replacement