Why does Redux keep global state in one store of plain serializable data, and what breaks if you store a Promise or class instance?

## The principle Redux describes itself with three principles. The first is **single source of truth**: *the global state of your application is stored in an object tree within a single store*. The style guide adds a rule to go with it: **only one Redux store per app**, created in one place and handed to the UI through a provider, not imported all over the code. The second half of the design is what the tree contains: **plain, serializable data**, meaning objects, arrays, strings, numbers, booleans and `null`. ## What one tree buys you - **Server rendering and hydration.** The server can build state, serialize it into the page and hand it to the client store as preloaded state with no custom code. - **Persistence.** Saving and restoring all or part of the tree is `JSON.stringify` and `JSON.parse`. - **Debugging.** One tree can be inspected, diffed between actions and exported as a snapshot. - **Replay.** Because every change is an action applied by pure reducers to plain data, recorded actions can be replayed to reproduce a bug. The DevTools' time travel is built on this. - **Undo/redo.** Keeping past versions of one tree is simple when the tree is immutable data. ## What breaks with non-serializable values | Value in state | What goes wrong | |---|---| | `Promise` | No serializable form; its status is invisible to tools; hydration cannot recreate it | | `Map` / `Set` | `JSON.stringify` turns them into `{}`, so persistence and hydration lose the data | | Class instance | Methods and prototype are lost on serialization; methods that mutate `this` change state in place | | Function | Dropped by JSON; cannot be inspected or replayed | | `Date` | Becomes a string on the way through JSON, so the type changes after a round trip | The in-place mutation point deserves emphasis. A class instance with an `addItem()` method that pushes into its own array changes the state **without producing a new reference**. UI bindings that compare references, as react-redux does, see "no change" and skip the render, and any snapshot tool now shows the mutated value in past states too. ## What the core does and does not enforce 1. **Actions**: the core `dispatch` throws unless the action is a plain object whose `type` is a string (Redux 5). 2. **State**: the core does **not** check state at all. `createStore` stores whatever the reducer returns. 3. **Development checks**: Redux Toolkit's `configureStore` adds development-only middleware that warns about non-serializable values and detects mutations. That is a Toolkit feature, not core behaviour. ## The documented exception Non-serializable values are acceptable **in actions** when a middleware intercepts and stops the action before it reaches reducers. A function dispatched to redux-thunk is the standard example: it never becomes state and never appears in the reducer's action log. ## One store, not several It is technically possible to call `createStore` twice, but the style guide lists **one store per app** among its essential rules, for concrete reasons: - **Actions cannot cross stores.** An action dispatched to store A never reaches store B's reducers, so one event that should update both needs two dispatches and can leave them inconsistent in between. - **The provider serves one store.** A React subtree gets its store from the nearest provider, so components that need data from two stores need awkward nesting or custom context. - **Tooling assumes one tree.** Snapshots, persistence and replay work on one state tree; several trees multiply the setup and cannot be replayed as one sequence. What scales instead is **one store with many slices**: each feature owns a reducer, and the root reducer composes them. The style guide also advises that application code should not import the store directly. It reaches components through the provider and other logic through middleware, which keeps tests and server rendering free to create their own store instances. ## What to store instead - Store **IDs and plain records**, not live objects such as sockets, class models or DOM nodes; keep those outside the store and look them up by ID. - Store **timestamps as numbers or ISO strings**, not `Date` objects. - Store **request status as data** (`'idle' | 'loading' | 'succeeded' | 'failed'`), not the Promise. - Keep **derived values** out of state and compute them when you read.