Redux Interview Questions — Hard

• configureStore composes middleware via compose(...middlewares)(store.dispatch) producing an enhanced dispatcher; each layer wraps the next, so calling enhanced dispatch enters middleware[0] first.
• The store keeps currentReducer, currentState; a boolean isDispatching guards re-entrancy - dispatching DURING a reducer throws ("Reducers may not dispatch actions"), preventing cascading corruption.
• After reducer returns, listeners array is snapshotted and iterated - subscribers added/removed during notification are handled safely for the current pass but affect future ones.
• State reference changes even when reducers return identical slices? No - combineReducers preserves identical slice references; root ref changes only if any slice changed (cheap bailout preserved).

---

• Modern react-redux subscribes via useSyncExternalStore with a memoized selector wrapper (useSelectorWithStore pattern): getSnapshot = latest selector result cached per subscription.
• Tearing: in concurrent rendering two components could read different store snapshots within one committed tree. useSyncExternalStore's consistency check forces re-render when snapshot mutates mid-render, closing the tear - provided your selector is pure & stable.
• Store authors must notify AFTER commit-friendly timing? Not required - notifications during render trigger the check path. But mutating state objects in place breaks snapshot identity assumptions entirely (never mutate).
• Interview depth: contrast with pre-18 store.subscribe + setState approach which could tear under transitions.

---

• Produce walks your draft mutations through ES2015 Proxy traps (set/get/deleteProperty), recording a patch list; finalize copies ONLY touched paths (copy-on-write at object granularity).
• Breakage cases interviewers probe:
  • Reading then relying on prototype methods of class instances stored in state (draft loses constructor unless tagged).
  • Async gaps: keeping a draft beyond the producer scope → revoked proxy errors.
  • Map/Set require plugins; Symbol-keyed fields ignored; extremely large arrays pay trap overhead.
  • Structural sharing guarantee holds only if you never escape-references drafts into results. Patches emitted alongside enable inverse-patch undo systems.

---

Two viable architectures:

1. Snapshot stack: wrap reducer to push {past:[...], present, future:[]} per tracked action whitelist; memory heavy but simple; partialize via key filtering to bound size.
2. Patch-based: capture Immer forward+inverse patches per action; apply inverses for undo, forwards for redo - orders of magnitude smaller for big normalized graphs. Hard parts to articulate: grouping rapid actions into logical steps (debounce windows / transaction markers), cross-slice atomicity (single history entry spanning slices via root wrapper), excluding volatile keys, and coalescing server reconciliations so network truth doesn't create undo steps.

---

Components:

• pendingMutations: { [entityId]: Queue<Op> } persisted slice; ops carry clientToken, baseRev.
• Reducer applies op optimistically AND bumps local rev; selector layer merges server cache beneath pending overlays.
• On fulfillment: replace overlay with canonical entity (rev from server); conflicts (server rev > baseRev) route to rebase strategy: field-level merge where user-touched fields win, else surface resolution UI.
• Refetch reconciliation must reapply pending overlays post-merge - implement as a single reconcileEntity helper ALL cache writes funnel through. Failure edges: abandoned tokens GC'd by TTL sweeper; double-submit prevented by token uniqueness per logical intent.

---