🗃️ Normalized State Structure

What Is Normalized State?

Normalization is a way of arranging data so that each piece of information lives in exactly one place. Instead of nesting an author object inside every post that references them, you store all authors in one table and let posts hold just the author's id. It's the same idea a relational database uses when it splits data across tables joined by foreign keys.

Today we're in Redux's advanced patterns. Normalization is the foundation the next two lessons build on: memoized selectors read from this flat shape, and the DevTools you'll set up afterward make its clean action-by-action diffs a joy to inspect.

The Problem With Nested State

When you fetch data from a typical REST API, it arrives as a deeply nested tree: posts contain author objects, comments contain their own author objects, and the same person shows up again and again. Drop that straight into your store and every copy drifts out of sync the moment one of them changes.

What denormalized state looks like

// ❌ Denormalized: John Doe is stored THREE times
const state = {
  posts: [
    {
      id: "post1",
      title: "First Post",
      author: { id: "user1", name: "John Doe", email: "john@x.com" },
      comments: [
        { id: "c1", text: "Great post!",
          author: { id: "user2", name: "Jane Smith", email: "jane@x.com" } },
        { id: "c2", text: "Thanks for sharing!",
          author: { id: "user1", name: "John Doe", email: "john@x.com" } } // dup!
      ]
    },
    {
      id: "post2",
      title: "Second Post",
      author: { id: "user2", name: "Jane Smith", email: "jane@x.com" }, // dup!
      comments: []
    }
  ]
};

The update that hurts

Now John changes his email. Because his data is scattered, you must crawl the entire tree and patch every copy — carefully, immutably, without missing one:

// ❌ Painful: rebuild the whole tree just to change one email
function updateUserEmail(state, userId, newEmail) {
  return {
    posts: state.posts.map(post => ({
      ...post,
      author: post.author.id === userId
        ? { ...post.author, email: newEmail }
        : post.author,
      comments: post.comments.map(comment => ({
        ...comment,
        author: comment.author.id === userId
          ? { ...comment.author, email: newEmail }
          : comment.author
      }))
    }))
  };
}

The Normalized Shape: byId & allIds

The standard normalized shape stores each entity type as an object keyed by id (byId) plus an array that remembers order (allIds). Lookups become instant, and order is preserved separately from the data.

// ✅ Normalized: every entity stored exactly once
const state = {
  users: {
    byId: {
      user1: { id: "user1", name: "John Doe", email: "john@x.com" },
      user2: { id: "user2", name: "Jane Smith", email: "jane@x.com" }
    },
    allIds: ["user1", "user2"]
  },
  posts: {
    byId: {
      post1: { id: "post1", title: "First Post",
               author: "user1", comments: ["c1", "c2"] }, // id references
      post2: { id: "post2", title: "Second Post",
               author: "user2", comments: [] }
    },
    allIds: ["post1", "post2"]
  },
  comments: {
    byId: {
      c1: { id: "c1", text: "Great post!",  author: "user2", post: "post1" },
      c2: { id: "c2", text: "Thanks!",      author: "user1", post: "post1" }
    },
    allIds: ["c1", "c2"]
  }
};

The update that no longer hurts

// ✅ One entity, one place, O(1) update
function updateUserEmail(state, userId, newEmail) {
  return {
    ...state,
    users: {
      ...state.users,
      byId: {
        ...state.users.byId,
        [userId]: { ...state.users.byId[userId], email: newEmail }
      }
    }
  };
}
// posts and comments are untouched — they only held the id "user1".

Four Normalization Principles

Every normalized store follows the same four rules. Internalize these and you can normalize any API response on sight.

1. Each entity type gets its own table

// Split articles, authors, and categories into separate tables
const normalized = {
  articles:   { byId: { 1: { id: 1, title: "Redux Tutorial", author: 1, category: 1 } }, allIds: [1] },
  authors:    { byId: { 1: { id: 1, name: "Dan Abramov" } },  allIds: [1] },
  categories: { byId: { 1: { id: 1, name: "Programming" } },  allIds: [1] }
};

2. Each entity is keyed by its id

Objects give you constant-time lookup; arrays force a linear scan. This is the single biggest performance reason to normalize.

// ✅ Object keyed by id — O(1) lookup
const byId = { user1: { id: "user1", name: "John" },
               user2: { id: "user2", name: "Jane" } };
const user = byId["user1"];                          // instant

// ❌ Array — O(n) scan grows with your data
const list = [{ id: "user1", name: "John" }, { id: "user2", name: "Jane" }];
const same = list.find(u => u.id === "user1");       // walks the array

3. Relationships are represented by ids

// ✅ Store ids, not embedded objects
const post = {
  id: "post1",
  author: "user1",                 // one-to-one → single id
  comments: ["c1", "c2"]           // one-to-many → array of ids
};

4. Arrays of ids preserve order

Objects don't guarantee key order, so keep any meaningful ordering in a separate allIds (or a UI-specific list). Sorting and filtering then just rearrange a small array of strings, never the entities themselves.

const state = {
  posts: {
    byId: {
      post1: { id: "post1", title: "First" },
      post2: { id: "post2", title: "Second" },
      post3: { id: "post3", title: "Third" }
    },
    allIds: ["post1", "post2", "post3"]      // canonical order
  },
  ui: {
    postFeed: ["post2", "post1", "post3"]    // a different, view-specific order
  }
};

createEntityAdapter: normalization for free

Writing byId/allIds reducers by hand is repetitive. Redux Toolkit's createEntityAdapter generates them for you. It stores data in a { ids: [], entities: {} } shape (the same idea — entities is byId, ids is allIds) and hands you prebuilt reducers and memoized selectors.

import { createSlice, createEntityAdapter } from '@reduxjs/toolkit';

// 1) Create an adapter. sortComparer keeps `ids` in a chosen order.
const postsAdapter = createEntityAdapter({
  sortComparer: (a, b) => b.createdAt.localeCompare(a.createdAt) // newest first
});

// 2) getInitialState() returns { ids: [], entities: {} }
//    and you can bolt extra fields onto it.
const initialState = postsAdapter.getInitialState({
  loading: false,
  error: null
});

// 3) The adapter's CRUD helpers mutate Immer draft state for you.
const postsSlice = createSlice({
  name: 'posts',
  initialState,
  reducers: {
    postsLoaded:  postsAdapter.setAll,     // replace everything
    postAdded:    postsAdapter.addOne,     // insert one
    postUpdated:  postsAdapter.updateOne,  // { id, changes }
    postRemoved:  postsAdapter.removeOne   // by id
  }
});

export const { postsLoaded, postAdded, postUpdated, postRemoved } = postsSlice.actions;

// 4) getSelectors() gives you memoized selectors keyed to this slice.
export const {
  selectAll:  selectAllPosts,   // returns an ordered array
  selectById: selectPostById,   // O(1) lookup by id
  selectIds:  selectPostIds
} = postsAdapter.getSelectors(state => state.posts);

export default postsSlice.reducer;

💡 Rule of thumb: If a slice holds a collection of things with ids, reach for createEntityAdapter first. Hand-rolled byId/allIds is worth understanding, but rarely worth writing in RTK projects.

Denormalizing for the UI

Normalized state is perfect for storing data but awkward for rendering it — a component wants a post with its author object and comment objects attached, not a pile of ids. The fix is a denormalizing selector: it reassembles the tree on read. Memoize it with createSelector (next lesson's star) so the reassembly only reruns when its inputs actually change.

import { createSelector } from '@reduxjs/toolkit';
import { selectPostById, selectAllPosts } from './postsSlice';

// Rebuild a single post with its author and fully-hydrated comments.
export const selectPostWithDetails = createSelector(
  [
    (state, postId) => selectPostById(state, postId),
    state => state.users.entities,
    state => state.comments.entities
  ],
  (post, usersById, commentsById) => {
    if (!post) return null;
    return {
      ...post,
      author: usersById[post.author],
      comments: (post.comments ?? []).map(commentId => ({
        ...commentsById[commentId],
        author: usersById[commentsById[commentId]?.author]
      }))
    };
  }
);

// For a LIST view, denormalize lightly — just enough to render.
export const selectPostSummaries = createSelector(
  [selectAllPosts, state => state.users.entities],
  (posts, usersById) =>
    posts.map(post => ({
      ...post,
      author: usersById[post.author],
      commentCount: post.comments?.length ?? 0   // count, not full comments
    }))
);

// PostDetail.jsx — the component stays blissfully simple
import { useSelector } from 'react-redux';
import { useParams } from 'react-router-dom';
import { selectPostWithDetails } from './postsSelectors';

function PostDetail() {
  const { postId } = useParams();
  const post = useSelector(state => selectPostWithDetails(state, postId));
  if (!post) return <p>Post not found</p>;

  return (
    <article>
      <h1>{post.title}</h1>
      <p>By {post.author?.name}</p>
      <section>
        <h3>Comments</h3>
        {post.comments.map(c => (
          <div key={c.id}>
            <p>{c.text}</p>
            <small>— {c.author?.name}</small>
          </div>
        ))}
      </section>
    </article>
  );
}

The normalizr Library

You can normalize an API response by hand, but for deeply nested payloads the normalizr library does it declaratively. You describe your entities and their relationships as schemas, and normalize() flattens any matching data into the { result, entities } shape.

// npm install normalizr
import { normalize, schema } from 'normalizr';

// Define the shape of your entities and how they relate.
const user    = new schema.Entity('users');
const comment = new schema.Entity('comments', { author: user });
const post    = new schema.Entity('posts',    { author: user, comments: [comment] });

const apiResponse = {
  id: "post1",
  title: "My Post",
  author: { id: "user1", name: "John Doe" },
  comments: [
    { id: "c1", text: "Nice post!", author: { id: "user2", name: "Jane Smith" } }
  ]
};

const normalized = normalize(apiResponse, post);
/* normalized =
{
  result: "post1",
  entities: {
    users:    { user1: {...}, user2: {...} },
    comments: { c1: { id: "c1", text: "Nice post!", author: "user2" } },
    posts:    { post1: { id: "post1", title: "My Post",
                         author: "user1", comments: ["c1"] } }
  }
}  */

// Pass an array schema to normalize a list; result becomes an array of ids.
const list = normalize([apiResponse], [post]);
// list.result === ["post1"]

Wire it into a thunk so data is flattened the moment it arrives — normalize at the API boundary, before it ever reaches your reducers:

export const fetchPosts = () => async (dispatch) => {
  const res  = await fetch('/api/posts?_embed=comments&_expand=author');
  const data = await res.json();
  const { entities } = normalize(data, [post]);

  dispatch(usersLoaded(entities.users   ?? {}));
  dispatch(postsLoaded(entities.posts   ?? {}));
  dispatch(commentsLoaded(entities.comments ?? {}));
};

Practice & Quiz

const users = [
  { id: "u1", name: "Ada" },
  { id: "u2", name: "Grace" }
];

function normalizeUsers(list) {
  // TODO: return { byId: {...}, allIds: [...] }
}
console.log(normalizeUsers(users));
// { byId: { u1: {id:"u1",name:"Ada"}, u2: {id:"u2",name:"Grace"} },
//   allIds: ["u1", "u2"] }

function normalizeUsers(list) {
  return {
    byId: list.reduce((acc, user) => {
      acc[user.id] = user;
      return acc;
    }, {}),
    allIds: list.map(user => user.id)
  };
}

function selectPostWithAuthor(state, postId) {
  const post = state.posts.byId[postId];
  if (!post) return null;
  return {
    ...post,
    author: state.users.byId[post.author]
  };
}
// Wrap in createSelector in a real app so it memoizes.

Best Practices & Pitfalls

✅ Do

• Store each entity once, in a table keyed by id
• Reference related entities by id, never by embedding objects
• Reach for createEntityAdapter for any id-based collection
• Normalize at the API boundary (in the thunk/query), before data hits reducers
• Denormalize on read with memoized selectors (see the next lesson)
• Keep UI state (loading, current filter, selected id) separate from entities

❌ Don't

• Store the same entity in two places and hope they stay in sync
• Nest entities inside other entities in the store
• Denormalize inside reducers or save assembled trees back into state
• Store derived data (counts, totals, sorted copies) — compute it in selectors
• Mix normalized and denormalized copies of the same data

Summary

📚 Additional Resources

• Redux — Normalizing State Shape
• Redux Toolkit — createEntityAdapter
• Redux — Updating Normalized Data
• normalizr — library documentation

🚀 What's Next?

You now have a flat, single-source-of-truth store. The catch: reading useful shapes out of it means computing derived data on every render. The next lesson, Selectors and reselect, shows how createSelector memoizes that work so denormalizing and filtering happen only when the data actually changes.