All topics
Stateadvanced

Normalizing State Shape

Learn why flattening nested, relational data into normalized entities improves update performance and avoids duplication.

Normalization is the practice of structuring state like a relational database — storing entities (users, posts, comments) in flat lookup tables keyed by ID, rather than deeply nested objects with duplicated copies of the same entity embedded in multiple places. A typical normalized shape looks like { users: { byId: {...}, allIds: [...] } }.

Normalized state is like a library's card catalog system: each book (entity) has exactly one physical copy on a shelf, and every reading list (relationship) just references the book's catalog number — update the book's description once in the catalog, and every list pointing to it reflects the change instantly, instead of each list keeping its own photocopy that needs updating separately.

Key Concepts

1
Deeply nested, denormalized state (e.g., a list of posts, each embedding its full author object) causes duplication: if a user updates their profile, every post embedding that user's old data needs to be found and updated too, or the UI shows inconsistent, stale copies. Normalization solves this by having only one canonical copy of each entity, referenced by ID from wherever it's needed.
2
Normalized state also makes updates cheaper and more predictable: updating one entity by ID is an O(1) lookup-and-replace in a flat table, rather than a deep, error-prone traversal and clone of nested structures. Redux Toolkit's createEntityAdapter provides ready-made reducer logic and selectors for exactly this normalized shape, including sorted ID lists and CRUD helper functions.
createEntityAdapter
3
Interviewers ask about normalization mostly in the context of complex, relational data — the classic example is a blog with posts, authors, and comments — expecting candidates to recognize duplication and stale-copy risks in nested state and propose a normalized byId/allIds structure as the fix.
byIdallIds