State Management

General definition

State Management is the set of decisions about where an application’s data lives, who may change it and how changes reach the screen. In a small React app, component-local state from hooks like useState is enough. As data is needed by many components that are far apart in the tree, teams lift it into a shared store so every part of the UI reads one source of truth and updates flow in a single, traceable direction.

The main options in the React ecosystem, from lightest to heaviest:

• Context + useReducer: built in, good for low-frequency data such as theme or the current user; every consumer re-renders on any change.
• Zustand, Jotai, Valtio: small stores with selective subscriptions, so only components that read a changed slice re-render.
• Redux Toolkit: a single immutable store with reducers, middleware and devtools; more ceremony, strongest audit trail of changes.
• MobX: observable objects that track which components read them.
• TanStack Query, SWR: not general stores but caches for server state, handling fetching, staleness and refetching.

Real-time applications stretch all of these. A chat client holds messages for many rooms, an unread count per room, a presence map that changes every few seconds, typing indicators, draft text and connection status, and updates arrive from the server rather than from user actions. The workable pattern is to normalise data (messages keyed by id and grouped by room), subscribe components to narrow slices, apply optimistic updates when the user sends and reconcile when the server acknowledges, and treat the server as the authority for anything that must survive a reload. React’s useSyncExternalStore, added in React 18, exists so external stores like these can feed React without tearing.

In the Ethora ecosystem

The Ethora Chat SDK takes the heaviest part of this off your store. The React chat component manages the real-time connection and its own message, presence and typing state internally, and the backend computes unread counts and the last message for each room server-side, so the client does not have to replay history to derive them. Your application store keeps what it already owns: the signed-in user, navigation, the currently open room and feature flags, and passes those in as props and callbacks.

That boundary works with any of the libraries above, from plain context to Redux Toolkit, because the component does not impose a store on the host app. The React Native SDK adds an encrypted local cache so recent messages survive a restart on the device. On the server side, message history, retention and per-user erasure are handled in the archive, which is the source of truth regulated customers can audit, rather than in whatever the client happens to hold.