Context or re-state?

React Context and re-state both share values, but they give those values different lifetimes. Context belongs to a provider tree. re-state belongs to the current JavaScript runtime and identifies each value with a key.

Neither choice is universally better. The important question is where the state should live.

At a glance

Concern	React Context	re-state
Setup	Context, provider, and consumer hook	A keyed hook or state module
Scope	One independent value per provider	One application-wide value per key
Access outside React	Usually needs a bridge or another store	Dispatchers, getters, and subscriptions are built in
Lifetime	Starts and ends with the provider tree	Persists for the JavaScript runtime
Render boundaries	Follow context consumers	Follow key subscriptions or selector results
Dependency	Included with React	Adds the re-state package

Choose Context when scope matters

Context is usually the better fit when:

The same page needs several independent instances, such as two editors or carts.
State should disappear when a provider subtree unmounts.
The nearest provider should decide which value a component receives.
Server-rendered or request-scoped state must be isolated per request.
You want dependency injection without another state-management package.

Rendering two providers creates two separate values. That provider ownership is a feature, not boilerplate to remove.

Choose re-state when reach matters

re-state is usually the better fit when:

Unrelated components should share one application-wide value.
Event handlers, utilities, services, or integrations need to read or update the state.
You want a useState-style API without mounting a provider.
A feature benefits from named hooks, actions, getters, and reset behavior in one module.
A selector needs to derive data from several keys.

With re-state, every consumer of the same key joins the same value:

export const { useTheme, dispatchTheme, getTheme } = createReStateMethods('theme', 'light');

Use distinct keys when values should be independent.

Rendering and subscriptions

Context consumers re-render when the context value they consume changes. Splitting contexts and keeping provider values stable can reduce unnecessary work.

re-state hooks subscribe to a key. useReStateSelector subscribes to the complete store but only re-renders the component when its selected result changes. Neither model guarantees that every render will be avoided; good subscription boundaries still matter.

A note about server rendering

re-state has one store per JavaScript runtime. In a long-lived server process, that store can outlive a request. Do not put request-specific or user-specific data in a shared runtime store unless your architecture creates proper isolation. Context is often the safer default for request-scoped state.

Moving between the two

To move provider-owned state into re-state:

Put the state shape and initial value in a module.
Replace the provider with createReStateMethods.
Move updates into actions next to the state.
Replace useContext calls with generated hooks.
Remove the provider after every consumer uses the module.

The reverse migration is just as valid when application-wide state needs provider scope or independent instances.

Use Context for provider-owned state. Use re-state when one keyed value should be reachable across the application.