Understanding State Management in React by Looking at Where State Lives

When developers first learn about state management in React, the conversation usually starts with tools.

Redux. Zustand. Jotai. MobX.

It can easily feel like choosing a state management library is the main decision you have to make.

But over time, it becomes clear that the real question is not which tool to use, but something more fundamental:

What kind of state are we dealing with?

Because not all state in a React application behaves the same way. Some state belongs to a single component, some needs to be shared across the interface, and some doesn’t even belong to the client at all.

Understanding these differences changes how you think about state management entirely.

Local State

Local state is the simplest form of state.

It lives inside a single component and only affects that component’s behavior.

Examples include:

• whether a modal is open
• the value of an input field
• a toggle switch
• a counter

This is the state most React developers interact with first.

const [isOpen, setIsOpen] = useState(false)

Local state is usually the best place to keep state whenever possible. It keeps components self-contained and avoids unnecessary complexity.

Many React applications can go surprisingly far using nothing more than local state.

Shared UI State

Eventually, some state needs to be shared between multiple components.

For example:

• the authenticated user
• theme settings
• layout preferences
• a modal controller

Passing this data through multiple layers of components leads to prop drilling.

To solve this, React provides Context.

Context allows state to be shared across a part of the component tree without manually passing props through every layer.

Instead of pushing data down through each component, any component inside the provider can access it directly.

This type of state still belongs to the UI, but its scope is larger than a single component.

Global Client State

Some state needs to exist at the application level.

Examples might include:

• a shopping cart
• application-wide settings
• user session information
• complex UI coordination

This is where global state libraries often appear.

Tools like Zustand, Jotai, MobX, and Redux create a store outside the React component tree that any component can subscribe to.

The main benefit is that the state becomes centralized and predictable, especially when many unrelated parts of the application depend on it.

However, modern React development has also shifted toward minimizing global state whenever possible. Many things that used to live in global stores can now remain local or scoped.

Server State

There is another category of state that behaves very differently from the others: server state.

This is data that comes from an external source such as an API or database.

Examples include:

• user profiles
• product lists
• notifications
• analytics data

Unlike UI state, server state has special challenges:

• it must be fetched asynchronously
• it may become stale
• it needs caching
• it may need refetching

Because of these requirements, modern React applications often use specialized tools like TanStack Query or SWR to manage server state.

Instead of manually fetching data and storing it inside a global store, these libraries handle caching, background updates, and synchronization automatically.

Why This Distinction Matters

Many state management problems appear when all types of state are treated the same way.

In the past, developers often stored everything inside a single global store. But this approach mixes concerns and increases complexity.

Modern React architecture tends to separate responsibilities.

Local state handles component behavior.

Context handles shared UI state.

Global stores handle cross-application state.

Server-state libraries manage remote data.

Each layer solves a different problem.

A Different Way to Think About State

Instead of asking:

Which state management library should I use?

It can be more helpful to ask:

Where should this state live?

Once that question is answered, the appropriate tool often becomes obvious.

Sometimes it’s just useState.

Sometimes it’s Context.

Sometimes it’s a global store.

And sometimes the state doesn’t belong in the client at all.

Understanding these distinctions is what turns state management from a confusing set of tools into a clear architectural decision.