How does Redux DevTools time-travel debugging work, and what in your reducers or state stops it from replaying correctly?

## What the DevTools record The Redux DevTools browser extension connects to a store through a store enhancer. Redux Toolkit's `configureStore` adds it automatically through its `devTools` option, which defaults to `true`; with plain Redux you compose the extension's enhancer yourself. Once connected, the extension keeps a **history**: - each action that reaches the reducers, in order; - the state computed after each action; - by default the last 50 actions (the extension's `maxAge` option), with older entries dropped. For each entry you can inspect the **Action** (type and payload), the **State** tree, and the **Diff** between the previous and next state. With `configureStore` in development, the `trace` option is on, so each action also carries the stack trace of the code that dispatched it — the fastest way to answer "who dispatched this?". ## How time travel works Time travel is a consequence of Redux's design: state is the result of applying reducers to a sequence of actions. 1. **Jump.** Selecting an earlier action replaces the store's current state with the state recorded after that action. React-Redux's subscriptions fire and the UI re-renders as it looked at that moment. No reducer runs. 2. **Skip.** Toggling an action off removes it from the sequence. The extension recomputes every later state by running the reducers again over the remaining actions, starting from the state before the skipped one. 3. **Replay and slider.** Moving through the history re-applies recorded states step by step, which makes it possible to watch a bug unfold. 4. **Export and import.** The history can be saved to a file and loaded elsewhere to reproduce a session, which relies on actions and state being serialisable. Only **actions** are in the history. A thunk is a function intercepted by middleware before it reaches the reducers, so its logic and network calls are never replayed; only the plain actions it dispatched appear. ## What breaks replay | Problem in the code | What you see in the DevTools | |---|---| | **Impure reducer** — `Date.now()`, `Math.random()`, reading `localStorage`, calling an API | skipping or replaying an action produces different states than the original run, or repeats side effects | | **Mutated state** — `state.items.push(x)` in a hand-written reducer, or a component editing a selected object | earlier snapshots change along with the current state; diffs show nothing and jumping back shows wrong data | | **Non-serialisable values** — class instances, `Map`, `Set`, `Date`, promises, functions | values display poorly, and export, import or persisted sessions lose or corrupt them | | **Huge state or payloads** | the extension becomes slow; the history consumes memory | Redux Toolkit guards against the first rows in development: Immer-based reducers make mutation-by-mistake rare, the immutability check throws on accidental mutation, and the serializability check logs non-serialisable values. ## Keeping the DevTools useful - Keep reducers **pure**; generate ids and timestamps in action creators or `prepare` callbacks so the values are recorded in the action itself. - Keep state **plain data**: ISO strings instead of `Date` objects, arrays and objects instead of `Map` and `Set`. - Use `actionSanitizer` and `stateSanitizer` to replace large blobs or sensitive fields in what the extension records, and `actionsDenylist` to hide noisy actions such as high-frequency ticks. - Lower `maxAge` if a long history makes the extension slow. - Give the store a `name` when a page hosts more than one, so the extension lists them separately. - Use descriptive action types such as `cart/itemAdded`; the history is read by type, and a log of generic `UPDATE` actions is hard to navigate. ## Production considerations `configureStore` leaves `devTools` enabled unless you disable it, so a production build will connect to the extension on a user's machine if it is installed, exposing the state and action history to anyone who opens it. Teams that store sensitive data commonly pass `devTools: process.env.NODE_ENV !== 'production'`, or keep it on with sanitizers when production debugging is worth the exposure. ## Interview summary - the extension records actions and resulting states through a store enhancer; - jump restores a recorded state, skip recomputes by re-running reducers; - replay depends on pure reducers, immutable updates and serialisable data; - thunks and other middleware side effects are not replayed.