The Absolute State of Management - Infrequently Noted
Skip to main content
Series
Reckoning
Browser Choice Must Matter
The Performance Inequality Gap
Effective Standards Work
Recently
The Wicked Reason Removing Code Beats Better Scheduling
The Absolute State of Management
Abject Praise
The Web Is An Antitrust Wedge
Naked Power<br>'25, '24, '23, '22, '21, '20, Earlier
Popular
The Absolute State of Management
If Not React, Then What?
Abject Praise
It is by no means the gravest linguistic crime of the React epoch,1 but "state management" grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this:
me: This UI is far too heavyweight for what it does, have you considered not using React?
them: But how will we do state management without React?
me: What do you mean? are reactive.
them: React manages state in our app.
me: It does? Then what are for?
them: Oh, those manage state.
me:
The libraries that trigger this "Who's on First?" routine include:
MobX, which promises "simple, scalable state management."
Satchel, apparently, "is characterized by exposing an observable state that makes view updates painless and efficient"
Recoil, billed as "a state management library for React"
Jotai, which pledges "primitive and flexible state management for React"
XState, a "state management and orchestration solution for JavaScript and TypeScript apps"
Apollo, promising "a comprehensive GraphQL state management library for JavaScript"
Redux, tagline: "a predictable state container for JavaScript apps."
TanStack Store, "a framework-agnostic state primitive for immutable updates"
Zustand, described as the "🐻 bear necessities for state management in React"
Contrasts sharp enough to cut softened butter.2
Suffice it to say, the ecosystem has not picked a winner. Indeed, I regularly see several of these libraries on a single page. But even one would seem too many, given that we're adding a second "state management" system to a framework that spills considerable documentation ink chest-beating about its state management facilities.
One of the following must be true:
React is a state management system and someone has smuggled in a duplicative dependency we can jettison.
React is an inadequate state management system and we should stop trusting it with an ill-defined subset of the "state management" problem.
React is not a state management system and we should stop pretending otherwise.
But in the to-and-fro of consulting engineering one can't just say as much, for fear of offence against frameworkist articles of faith.3
Thankfully, this is a blog post, so we can cut to the chase and admit that none of these tools manage state.
They might encapsulate state. They might even filter or transform updates. But they do not, in any meaningful way, manage state, settling for merely propagating notifications about state changes and in some cases facilitating ad-hoc post-processing or caching.4 Conceptually, they are expressively equivalent to event buses and pub/sub systems, which are better recognised as message passing backplanes.5
True state management wrestles with the time dimension, but React-centric "state management" libraries handle time the way C++ does for multithreaded code — which is to say, it's left as an exercise to the reader.6
Systems without a built-in conception of time and ordering are subject to temporal effects. They can even synthesise compound state out of unordered, un-timestamped updates. But they occupy a world of hopes and dreams when it comes to asserting affirmative management of state because managing state means correctly applying changes over time and resolving conflicts.
Then and Now and When
A large fraction of the problems from overgrown React and Redux attempts at "state management" spring from the same wellstone: updates to the state propagation systems come from a variety of sources, with varying frequency and specificity. Pure propagation systems crumble under the incidental complexity that results from trying to sort out the consequences with only an event bus abstraction. It becomes unclear whose job it is to sort out which updates are "correct", and optimistic UI updates become a liability — or at least a bun fight.
At bottom, this is the same problem as managing data across multiple machines, and managing data over the network is the same as managing it across time that spans from the past, to the current moment, as well as the future.
This insight is important because it allows us to consider what's currently in memory vs. the same app rebooted at some future point without losing our minds. A future local instance of an app is conceptually the same as the app booting on an entirely different computer. Getting crisp on this is the key to throwing out jejune notions of "state management" and replacing them with tools that are fit for purpose.
Systems that manage state — rather than merely propagating or filtering...