That's backwards. React is a tool for writing declarative UI (or declarative anything really) that can handle state updates. Probably they're using it because it's the best tool around for that job.
Well it depends if you're talking about React the UI library or React the increasingly popular underlying architecture. The former is vastly more popular by usage (I mean.. I assume) but the underlying approach to declarative-in-imperative turns out to work in other settings and seems to be gaining traction.
Sure but the essence of it, the reason that it works, is that it shims a declarative architecture into JS. It works because it turns out UI programming works better in a declarative style.The fact that that involves managing state is secondary.
I expect that in fifty years all programming will look declarative, either like HTML (which is sorta 'natively declarative') or more like React (which shims it into an imperative language).
That is a silly way to phrase it. It's secondary in the sense that of course a UI framework has to manage state. They all do that if they're complex at all. The state management is not what distinguishes React from other frameworks; it is distinguished by the (pseudo-)declarative API that it presents to the programmer.
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.
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
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.
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:
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.
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.
> 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).
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:
