FE Design

Normalized State

A state management pattern where data is stored as a flat, relational structure—typically using objects keyed by IDs (lookup tables)—rather than nested tree structures, mirroring a relational database schema on the client.

Cheat Sheet

Prime Use Case

Essential for applications with complex data relationships, shared entities across multiple views, or high-frequency real-time updates where data consistency is paramount.

Critical Tradeoffs

  • Ensures data consistency across the UI
  • Optimizes update performance (O(1) lookups)
  • Increases architectural boilerplate
  • Requires a 'denormalization' step for view rendering

Killer Senior Insight

Normalization decouples the data's 'source of truth' from the UI's 'view hierarchy,' preventing the 'stale data' bug where an entity is updated in one component but remains outdated in another.

Recognition

Common Interview Phrases

How do we handle a user liking a post that appears in both the Feed and their Profile?
What happens if the same entity is returned by multiple API endpoints?
How do we minimize re-renders when a single property of a deeply nested object changes?

Common Scenarios

  • Social media feeds with shared user/post entities
  • E-commerce dashboards with complex order/product relationships
  • Collaborative tools like Slack or Notion where messages/pages are referenced in multiple contexts

Anti-patterns to Avoid

  • Normalizing simple, flat lists that are never shared or updated
  • Using normalization for transient UI state like 'isDropdownOpen'
  • Manually syncing duplicate data across different slices of state

The Problem

The Fundamental Issue

The 'Single Source of Truth' violation in nested state, where updating a shared entity requires traversing and mutating multiple parts of the state tree.

What breaks without it

Inconsistent UI (e.g., a username changes in the header but not in the comment list)

Performance degradation due to deep cloning of large nested objects for immutable updates

Memory leaks from storing multiple copies of the same large data object

Why alternatives fail

Prop drilling nested data makes components brittle and tightly coupled to the API response shape

Denormalized state requires O(N) or O(N^2) operations to find and update specific items

Context-based solutions still suffer from the 'update everywhere' problem if the data is duplicated

Mental Model

The Intuition

Think of a library: instead of putting a full copy of the author's biography inside every single book they wrote, you have one 'Authors' file and each book just contains the Author's ID. When the author wins an award, you update one file, and every book 'references' the new info.

Key Mechanics

1

Entities: Objects keyed by unique IDs (e.g., state.users[id])

2

Result Sets: Arrays of IDs representing order or filtered views (e.g., state.postIds = [1, 2, 3])

3

Selectors: Functions that 'join' entities back together for the UI (Denormalization)

4

Schemas: Definitions that describe how to parse nested API responses into flat tables

Framework

When it's the best choice

  • When the same data entity is rendered in multiple UI components simultaneously
  • When the application requires optimistic UI updates for complex actions
  • When the API returns deeply nested or redundant JSON structures

When to avoid

  • Small-scale applications with minimal data interactivity
  • Read-only dashboards where data is fetched, displayed once, and discarded
  • When using GraphQL clients like Apollo or Relay that handle normalization automatically

Fast Heuristics

If data is shared
Normalize
If data is local to one view
Keep it simple/nested
If performance is the bottleneck during updates
Normalize

Tradeoffs

+

Strengths

  • Predictable state updates: you only ever update one object
  • Efficient re-renders: components can subscribe to specific IDs
  • Simplified logic for CRUD operations (Create, Read, Update, Delete)
  • Easier implementation of Undo/Redo and Time Travel debugging
−

Weaknesses

  • Higher cognitive load for developers to map state to view
  • Increased boilerplate (selectors, schemas, action creators)
  • Potential for 'Orphaned Entities' if deletion logic isn't robust

Alternatives

Denormalized/Nested State
Alternative

When it wins

Simple apps where data is strictly hierarchical and never overlaps.

Key Difference

Data is stored exactly as it is received from the API.

Atomic State (Jotai/Recoil)
Alternative

When it wins

When you want to avoid a central store and prefer distributed, independent pieces of state.

Key Difference

State is split into 'atoms' rather than a single relational tree.

Graph-based Clients (Apollo/Relay)
Alternative

When it wins

When using GraphQL; these tools provide normalization out-of-the-box.

Key Difference

Normalization is an implementation detail of the cache, not a manual task for the developer.

Execution

Must-hit talking points

  • Mention 'O(1) lookup' for entity updates
  • Discuss 'Referential Equality' and how it prevents unnecessary re-renders
  • Explain the role of 'Selectors' in re-assembling data for the view layer
  • Reference 'Normalizr' as the industry-standard utility for this pattern

Anticipate follow-ups

  • Q:How do you handle garbage collection of entities no longer in use?
  • Q:How does normalization interact with pagination and infinite scroll?
  • Q:What are the implications for memoization (e.g., using useMemo or Reselect)?

Red Flags

Normalizing UI state (e.g., 'isModalOpen')

Why it fails: Adds unnecessary complexity to state that doesn't have relational properties or shared identity.

Forgetting to use memoized selectors

Why it fails: Denormalizing data on every render can be expensive, negating the performance benefits of a flat state.

Deeply nesting the 'Result' arrays

Why it fails: Defeats the purpose of flattening; the 'Result' (list of IDs) should remain as flat as possible.