# Why "state management" is a misleading term in React

DevFeed: [Why "state management" is a misleading term in React](<https://devfeed.tech/articles/the-absolute-state-of-management-26566.md>)

Original publisher: [Read original article](<https://infrequently.org/2026/07/state-management/>)

Author: Alex Russell

Published: 2026-07-23T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>)

Tags: [alternatives](<https://devfeed.tech/tags/alternatives.md>), [frameworkism](<https://devfeed.tech/tags/frameworkism.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [library](<https://devfeed.tech/tags/library.md>), [react](<https://devfeed.tech/tags/react.md>), [redux](<https://devfeed.tech/tags/redux.md>), [state-management](<https://devfeed.tech/tags/state-management.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

## AI overview

This opinion article argues that "state management" is an imprecise label for React and the surrounding ecosystem. It surveys libraries including Redux, Zustand, Apollo, and others, and contends that they primarily encapsulate state or propagate notifications about state changes rather than manage state themselves.

## Source excerpt

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? <alternatives> are reactive. them: React manages state in our app. me: It does? Then what are <various_libraries> 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 s