The Cognitive Load of Modern State Management
In 2016, if you wanted to toggle a modal in a React application, you wrote an action creator, a reducer case, updated the store, connected a component, and dispatched the action. It was verbose. It was annoying. But it was also incredibly obvious. You could trace the line of execution from the click handler to the state update with your eyes closed.
Today, we have "solved" this verbosity. We have signals, atoms, proxies, and hooks that auto-subscribe to changes. We can mutate state directly and let the compiler figure out the dependency graph. We can write `count.value++` and watch the UI update by magic.
But as our tools have become more "magical," our mental models have become more fragile. We traded the typing tax of Redux for a cognitive tax that we pay every time we try to debug a race condition or understand why a component is re-rendering four times in a row.
We didn't eliminate the complexity of state management. We just moved it from our keyboards to our heads.
The Demonization of Prop Drilling
It started with the war on "prop drilling." Somewhere along the line, passing data down three levels of components became viewed as an architectural sin. We treated it like a code smell, ignoring the fact that explicit data passing is the cornerstone of predictable software.
Prop drilling is just dependency injection. It is explicit. It says, "This child component depends on this specific piece of data from its parent." When you look at the component interface, you know exactly what it needs to function.
To avoid this "pain," we reached for Context, then Recoil, then Zustand, then Signals. We created wormholes in our component tree where data could teleport from the root to a leaf node without touching anything in between.
This felt like liberation. But it broke the encapsulation of our components. Suddenly, a button deep in the tree isn't just a button; it's a node implicitly coupled to a global state store defined ten files away. You can no longer just drop that component into a Storybook or a test without mocking an entire universe of providers and stores.
The "Magic" of Fine-Grained Reactivity
The current darling of the frontend world is fine-grained reactivity—Signals. The promise is seductive: never worry about dependency arrays again. The framework tracks what you use and updates only what changed.
On the surface, this is a win for performance and developer experience. But it introduces a new kind of uncertainty: Action at a Distance.
When reactivity is implicit, it becomes invisible. In a explicit dependency model (like `useEffect` with a dependency array), the triggers are declared. You might hate writing them, but they are there. In an implicit model, a read operation is also a subscription. Simply looking at a value changes how your component behaves.
This leads to "Heisenbugs"—bugs that appear or disappear based on how you observe the system. Did logging that value to the console accidentally create a subscription? Did destructuring that object break the proxy tracking? The rules of the language JavaScript are being subtly rewritten by the framework runtime, and you have to keep those rewritten rules in your head.
The Cost of Invisible Mutations
Immutability was hard. Writing `...state, user: { ...state.user, name: 'Alice' }` is tedious. So libraries like Immer and Signals gave us back mutation. `state.user.name = 'Alice'`.
But immutability wasn't just about making React's reconciliation step easier. It was about predictability. With immutable data, if you held a reference to an object, you knew it wouldn't change under your feet. Time was discrete. You had State at T1, and State at T2.
With observable mutation, time is continuous and slippery. A reference you hold might be updated by a side effect in a different part of the app. To reason about your component, you can't just look at its inputs; you have to understand the entire network of mutable state it connects to.
We are slowly re-inventing two-way data binding, realizing why we abandoned it in 2013, and rebranding it as "modern DX."
Complexity is Conserved
Tesler's Law states that for any system, there is a certain amount of complexity that cannot be reduced. It can only be moved.
Redux moved complexity to the code structure. You had to write a lot of files. You had to follow strict patterns. But the runtime behavior was simple.
Modern State Managers move complexity to the mental model. The code is concise. You write very little. But the runtime behavior is complex. You have to understand proxies, stale closures, automatic dependency tracking, and optimization bail-outs.
When things go wrong—and they always do—I would rather debug verbose code than magic code. Explicit code tells you what it's doing. Magic code hides what it's doing, assuming it knows better than you.
Choosing Where to Pay the Tax
This isn't a call to go back to Redux boilerplate. It's a call to be honest about the trade-offs. We often sell new tools solely on the "Happy Path"—look how easy it is to make a counter increment!
But we don't build counters. We build dashboards with real-time data, optimistic UI updates, and complex validation logic. In those scenarios, "easy" often becomes a trap.
Before reaching for the latest state management library that promises "zero boilerplate," ask yourself:
- Does this hide complexity I actually need to see?
- Can I debug this without a dedicated browser extension?
- Does this couple my UI components to my data layer?
- Is `useState` and `props` actually enough?
Most of the time, the answer to the last question is "yes." We underestimate the power of simple, local state because we have been conditioned to believe that "App State" is a monolithic entity that must be managed globally.
Local state is isolated. It deletes itself when the component unmounts. It doesn't need to be cleaned up. It doesn't cause re-renders in siblings. It is the ultimate low-cognitive-load state management.
The Case for Boring State
I am tired of "clever" state management. I am tired of knowing how a library abuses `WeakMap` to make my code look 10% cleaner.
Give me boring state. Give me explicit updates. Give me a variable that only changes when I tell it to. It might take five extra minutes to type out, but it will save me five hours of debugging on a Friday afternoon three years from now.