A Case for setState

State management is hard. And a lot of very smart and very vocal people each have their own opinion on the best way it should be done. Unfortunately, people gravitate towards loud voices and shiny things, even when the blunt hammer drives the straightest nail.

Unfortunately, people gravitate towards loud voices and shiny things, even when the blunt hammer drives the straightest nail.

But what are libraries like Redux, Alt, or MobX really trying to do? It’s all about stripping out the imperative and replacing it with the declarative. But you don’t need one of those libraries to achieve that. In fact, I find myself utilizing Redux principals daily outside of the Redux context. Immutable state with reducers is predictable and beautiful. But not Redux specific!

In my most recent open-source project, react-bash, my component state was immutable, and the bash actions were essentially reducers. You can see the source code here. Check out the commands file and you’ll see that each command is a reducer that immutably updates the state, but there’s no Redux in sight.

export const clear = {
    exec: (state) => {
        return { ...state, { history: [] } };
    },
};

But setState can’t share state! Well state management may be your answer in this case. Or maybe not. I could create the same basic effect of react-redux by sticking a single function on the root React component context that calls setState on that root component. And if your tree is shallow enough, a simple callback is far easier to manage than a library integration.

But setState is asynchronous and that’s bad! If you’re a web engineer and can’t deal with asynchronous code, you have bigger issues than your state. Asynchronicity is not inherently bad. In fact, there are important reasons why it was designed that way. Like any API, if you don’t know what it does then you’re going to have issues. But now you know, setState is asynchronous so expect that behavior :)

If your app is small, you don’t need a state manager, you need to learn to manage state.

But setState has a bad API! Seriously? I don’t get this argument. It is literally the most intuitive interface I can think of. I want to update my current state with these changes. Isn’t that exactly what all of the state management libraries are doing, too? Dispatching an event is essentially a round-a-bout way of saying, “update my current state with these changes, just do it over there.”

But setState doesn’t work with functional components! Yup. If your entire app is functional components then you don’t need React. Seriously. React thrives due to its component lifecycle and inherent state management. If everything is a functional component, you might as well just use template string interpolation. But it’s probably not. Chances are your root component is a class, and is the quintessential example of when and where to use setState.

SetState is a developer’s best friend.

Disagree? Tweet me all your rage @zackargyle.