Redux is far from the suggestion, and imho unless you can greatly benefit from the actions boilerplate its overhead is not worth it.

As others mentioned useImmer is a more bulletproof solution then assuming your state can always be modeled by a single layer Object though.

Redux Toolkit doesn't require much boilerplate anymore (IMHO). I found Redux to be absolutely appalling and never used it (despite having some familiarity with functional programming and the ideas underlying Redux) before RTK came along.

Heh, glad to hear that RTK is an improvement there :)

I too felt like that for a long time. Eventually I got when and why Redux is useful, even with the boilerplate. Also, modern semantics and utilities greatly help. Redux Toolkit, RTK Query, reselect and so on.

Actions make state more debuggable. Selectors make rendering more performant and often help structure complex rendering logic. Also, Redux is a way of not having to define asynchronous control flow by composing components, which can get really messy.

Granted, it's not necessary for every app.

I like Redux because it's portable—you can easily rip it out of a React project and use it anywhere—and because it provides a really nice way to separate backend-talking-stuff from frontend-rendering-stuff, if you're dividing up dev tasks. Nice clean place to split off a library for whatever service(s) you're consuming.

And with Typescript, it's not a bit unpleasant to work with.

Completely agree, also individual named state hooks are great for semantic reasons, they will make your code more readable and more easily maintainable.

the whole point of setState is that it forces you to think about component state from a centralized point of view and help avoid modeling it the wrong way (eg a bunch of optionals instead of an union type for the whole state). If you split them to a bunch of states then state becomes just mutable var in a different syntax.

That's not really true. Regardless how many setters you have or invoke, state only changes between renders. Of course state is mutable, that's the whole point. It's not mutable during the render function though. It's also easier to accidentally mutate an object assigned to a const than a string or number.

Also, the setters are usually passed around all over the place, so no, I don't think the point is centralizing component state at all.

centralizing as in when you setState({ a: true }), you also think "wait a minute is having a `state.b` still makes sense, now that "a" is `true`", maybe it should be setState({ a: true, b: null })

> It's not mutable during the render function

I don't think that's the point at all when people talk about mutability. To me mutability is just a proxy for "lacking access control", which again goes back to the point about centralizing state updates. So arguing about the technicality of what is mutable and what is not is pointless.

They’re much different than mutable variables with a different syntax. Changing them causes your component to render and reflect changes.

that doesn't matter. Look at frameworks in which you have states that when mutated, trigger a rerender, such as svelte. Suddenly (scattered) setState calls are not very different than (scattered) assignment statements