Managing Normalized Data

    One approach is to merge the contents of the action into the existing state. In this case, we need to do a deep recursive merge, not just a shallow copy. The Lodash function can handle this for us:

    This requires the least amount of work on the reducer side, but does require that the action creator potentially do a fair amount of work to organize the data into the correct shape before the action is dispatched. It also doesn't handle trying to delete an item.

    If we have a nested tree of slice reducers, each slice reducer will need to know how to respond to this action appropriately. We will need to include all the relevant data in the action. We need to update the correct Post object with the comment's ID, create a new Comment object using that ID as a key, and include the Comment's ID in the list of all Comment IDs. Here's how the pieces for this might fit together:

    1. // actions.js
    2. function addComment(postId, commentText) {
    3.   // Generate a unique ID for this comment
    4.   const commentId = generateId('comment')
    6.   return {
    7.     type: 'ADD_COMMENT',
    8.     payload: {
    9.       postId,
    10.       commentId,
    11.       commentText
    12.     }
    13.   }
    14. }
    16. // reducers/posts.js
    17. function addComment(state, action) {
    18.   const { payload } = action
    19.   const { postId, commentId } = payload
    21.   // Look up the correct post, to simplify the rest of the code
    22.   const post = state[postId]
    24.   return {
    25.     ...state,
    26.     // Update our Post object with a new "comments" array
    27.     [postId]: {
    28.       ...post,
    29.       comments: post.comments.concat(commentId)
    30.     }
    31.   }
    32. }
    34. function postsById(state = {}, action) {
    35.   switch (action.type) {
    36.     case 'ADD_COMMENT':
    37.       return addComment(state, action)
    38.     default:
    39.       return state
    40.   }
    41. }
    43. function allPosts(state = [], action) {
    44.   // omitted - no work to be done for this example
    45. }
    47. const postsReducer = combineReducers({
    48.   byId: postsById,
    49.   allIds: allPosts
    50. })
    52. // reducers/comments.js
    53. function addCommentEntry(state, action) {
    54.   const { payload } = action
    55.   const { commentId, commentText } = payload
    56.   // Create our new Comment object
    57.   const comment = { id: commentId, text: commentText }
    59.   // Insert the new Comment object into the updated lookup table
    60.   return {
    62.     [commentId]: comment
    63.   }
    64. }
    66. function commentsById(state = {}, action) {
    67.   switch (action.type) {
    68.     case 'ADD_COMMENT':
    69.       return addCommentEntry(state, action)
    70.     default:
    71.       return state
    72.   }
    73. }
    75. function addCommentId(state, action) {
    76.   const { payload } = action
    77.   const { commentId } = payload
    78.   // Just append the new Comment's ID to the list of all IDs
    79.   return state.concat(commentId)
    80. }
    82. function allComments(state = [], action) {
    83.   switch (action.type) {
    84.     case 'ADD_COMMENT':
    85.       return addCommentId(state, action)
    86.     default:
    87.       return state
    88.   }
    89. }
    91. const commentsReducer = combineReducers({
    92.   byId: commentsById,
    93.   allIds: allComments
    94. })

    Other Approaches

    Since reducers are just functions, there's an infinite number of ways to split up this logic. While using slice reducers is the most common, it's also possible to organize behavior in a more task-oriented structure. Because this will often involve more nested updates, you may want to use an immutable update utility library like or object-path-immutable to simplify the update statements. Here's an example of what that might look like:

    This approach makes it very clear what's happening for the "ADD_COMMENTS" case, but it does require nested updating logic, and some specific knowledge of the state tree shape. Depending on how you want to compose your reducer logic, this may or may not be desired.

    The library provides a very useful abstraction layer for managing normalized data in a Redux store. It allows you to declare Model classes and define relations between them. It can then generate the empty "tables" for your data types, act as a specialized selector tool for looking up the data, and perform immutable updates on that data.

    1. // models.js
    2. import { Model, fk, attr, ORM } from 'redux-orm'
    4. export class Post extends Model {
    5.   static get fields() {
    6.     return {
    7.       id: attr(),
    8.       name: attr()
    9.     }
    10.   }
    12.   static reducer(action, Post, session) {
    13.     switch (action.type) {
    14.       case 'CREATE_POST': {
    15.         Post.create(action.payload)
    16.         break
    17.       }
    18.     }
    19.   }
    20. }
    21. Post.modelName = 'Post'
    24.     return {
    25.       id: attr(),
    26.       text: attr(),
    27.       // Define a foreign key relation - one Post can have many Comments
    28.       postId: fk({
    29.         to: 'Post', // must be the same as Post.modelName
    30.         as: 'post', // name for accessor (comment.post)
    31.         relatedName: 'comments' // name for backward accessor (post.comments)
    32.       })
    33.     }
    34.   }
    36.   static reducer(action, Comment, session) {
    37.     switch (action.type) {
    38.       case 'ADD_COMMENT': {
    39.         Comment.create(action.payload)
    40.         break
    41.       }
    42.     }
    43.   }
    44. }
    45. Comment.modelName = 'Comment'
    47. // Create an ORM instance and hook up the Post and Comment models
    48. export const orm = new ORM()
    49. orm.register(Post, Comment)
    51. // main.js
    52. import { createStore, combineReducers } from 'redux'
    53. import { createReducer } from 'redux-orm'
    54. import { orm } from './models'
    56. const rootReducer = combineReducers({
    57.   // Insert the auto-generated Redux-ORM reducer.  This will
    58.   // initialize our model "tables", and hook up the reducer
    59.   // logic we defined on each Model subclass
    60.   entities: createReducer(orm)
    61. })
    63. // Dispatch an action to create a Post instance
    64. store.dispatch({
    65.   type: 'CREATE_POST',
    66.   payload: {
    67.     id: 1,
    68.     name: 'Test Post Please Ignore'
    69.   }
    70. })
    72. // Dispatch an action to create a Comment instance as a child of that Post
    73. store.dispatch({
    74.   type: 'ADD_COMMENT',
    75.   payload: {
    76.     id: 123,
    77.     text: 'This is a comment',
    78.     postId: 1
    79.   }
    80. })

    The Redux-ORM library maintains relationships between models for you. Updates are by default applied immutably, simplifying the update process.

    Another variation on this is to use Redux-ORM as an abstraction layer within a single case reducer:

    By using the session interface you can now use relationship accessors to directly access referenced models:

    1. const session = orm.session(store.getState().entities)
    2. const comment = session.Comment.first() // Comment instance
    3. const { post } = comment // Post instance