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.
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.
> 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.
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.
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-cont...
[2] - https://beta.reactjs.org/learn#updating-the-screen
[3] - https://beta.reactjs.org/learn#sharing-data-between-componen...