Redux that survives a complex checkout
A checkout looks simple until you list everything it tracks: the cart, the user, addresses, shipping options, payment methods, validation, promo codes, and the in-flight requests behind all of them. On a large app that state outgrows component hooks fast. Here is what keeps a big Redux store sane.
Normalize the state, do not nest it
Storing entities in nested arrays means updating one item forces you to walk the tree. Keep entities in a flat map keyed by id, and reference them by id elsewhere. Updates become a single key write, and you stop fighting deep immutable updates.
Put reads behind selectors
Components should not reach into the store shape directly. A selector is the one place that knows where data lives and how to derive it, the cart total, whether checkout is ready to submit. When the shape changes you update the selectors, not fifty components. Memoize the expensive ones.
Keep side effects out of components
Network calls, retries, and sequencing (validate the address, then fetch shipping, then recalculate totals) do not belong in a component effect. Move them to a dedicated layer, a saga or middleware, so components stay about rendering and the async flow lives in one testable place.
Type the state, especially the edges
TypeScript earns its keep at the boundaries: the shape of an API response, the action payloads, the selector return types. Most checkout bugs are a field that was sometimes undefined. Types turn those into compile errors instead of a blank total at the worst moment.
Redux gets a bad reputation from tutorials that show a counter. On a real checkout with dozens of interdependent pieces, the discipline it forces, one state shape, explicit updates, side effects in one place, is exactly what keeps the thing maintainable as it grows.