Gain insights into modern Redux usage with Redux Toolkit and React-Redux hooks. Delve into updated patterns and practices through comprehensive tutorials. Explore and apply contemporary Redux concepts.

Hi, I'm Mark Erikson, also known as @acemarke, and I'm a Redux maintainer

I wrote this course in 2017. Many of the concepts are still relevant, but Redux usage has changed significantly. We now teach Redux Toolkit as the standard approach for writing Redux logic, and React-Redux hooks as the default for components.

I'd recommend reading through the Redux core docs tutorials, which have been rewritten to explain the "modern Redux" patterns we teach today:

https://redux.js.org/tutorials/index

I've made this course free if you'd still like to go through it.

Robin Wieruch

Mark helps people learn Redux almost every day.  I guess he has seen all the challenging questions about it by now. So if you are learning Redux, I highly recommend to go with his course, because it comes with all his gathered experiences about the topic

Author of "The Road to Learn React"

Dave Ceddia

Practical Redux is the missing manual for how to use Redux in real-world apps, full of practical ideas on project structure, handling complex data, and best practices. I highly recommended it for anyone using Redux in a real app.

Author of "Learn Pure React"

Gosha Arinich

Mark is _the_ guy when it comes to explaining Redux. The course builds upon (& goes above and beyond) his awesome series of posts on Practical Redux. It’s full of actionable advice that applies to a range of apps… there were a couple of things I myself learned from it, and I’m no stranger to Redux. Definitely a must!

Author of "The Missing Forms Handbook of React"

Practical Redux

I primarily use Redux-ORM as a specialized "super-selector" and "super-immutable-update" tool.  This means that I work with it in my selector functions, thunks, reducers, and `mapState` functions.  Here's some of the practices I've come up with.


# Entity Selection

Because I consistently use the `ORM` singleton instance across my application, I've created a selector that encapsulates extracting the current `entities` slice and returning a `Session` instance initialized with that data:

```js
import {createSelector} from "reselect";
import orm from "./schema";

export const selectEntities = state => state.entities;

export const getEntitiesSession = createSelector(
    selectEntities,
    entities => orm.session(entities),
);
```

Using that selector, I can retrieve a `Session` instance inside of a `mapState` function, and look up pieces of data as needed by that component.

This has a couple benefits.  In particular, because many different `mapState` functions might be trying to do data lookups right in a row, only one `Session` instance should be created per store update, so this should be something of a performance optimization.  Redux-ORM does offer a `createSelector()` function that is supposed to create optimized selectors that track which models were accessed, but I haven't yet gotten around to actually trying that.  I may look into it later when I do some perf/optimization passes on my own application.

On the other hand, since `Session` instances replace their `session.state` value when they apply updates, it's a bad idea to reuse the current `Session` from that selector if you need to do any kind of update operations.  I always create new `Session` instances inside my reducers, and also in places like thunks or sagas where I might want to generate new items before including them in an action.  I wrote a small selector to help with that process:

```js
export function getUnsharedEntitiesSession(state) {
    const entities = selectEntities(state);
    return schema.from(entities);
}
```

Overall, I make it a point to keep all my components unaware of Redux-ORM's existence, and only pass plain data as props to my components.  That means I usually will read the `model.ref` property to retrieve the real underlying JS object from the store, and include that as part of the return value in `mapState`.



# Writing Entity-Based Reducers

Most of my entity-related reducers are based more around a specific action case rather than a certain Model class.  Because of this, some of my reducers are fairly generic, and take an item type and an item ID as parameters in the action payload.  As an example, here's a generic reducer for updating the attributes of any arbitrary Model instance:

```js
export function updateEntity(state, payload) {
    const {itemType, itemID, newItemAttributes} = payload;

    const session = orm.session(state);
    const ModelClass = session[itemType];

    let newState = state;

    if(ModelClass.hasId(itemID)) {
        const modelInstance = ModelClass.withId(itemID);

        modelInstance.update(newItemAttributes);

        newState = session.state;
    }

    return newState;
}
```

Not all my reducers are this generic - some of them do end up specifically referencing certain model types in specific ways.  In some cases, I can build up higher-level functionality by reusing these generic building block reducers.

My reducers generally follow the same pattern: extract parameters from payload, create Session instance, apply updates to models and return the new state from `session.state`.  There's admittedly some verbosity there, which I could probably abstract out a bit more if I wanted to, but the overall consistency and the simplification of the actual update logic is a big win in my book.

I've also written a couple small utilities that aid with the process of looking up a given model by its type and ID:

```js
export function getModelByType(session, itemType, itemID) {
    const modelClass = session[itemType];
    const model = modelClass.withId(itemID);
    return model;
}

export function getModelIdentifiers(model) {
    return {
        itemID : model.getId(),
        itemType : model.getClass().modelName,
    };
}
```

Many of my actions contain `itemType` and `itemID` pairs in their payloads.  Part of that is that I personally lean towards keeping my actions fairly minimal, with more work in the thunks _and_ the reducers as necessary, and don't like blindly merging data from an action straight into my state.


# Handling Iterative Updates

In Redux-ORM 0.8.x, processing multiple updates in a row could be a bit tricky, especially if later steps of the update process needed refer to some of the earlier results while those earlier update steps were still queued up and waiting to be applied.  Fortunately, 0.9's changes to `Session` update behavior simplified things.  The current `session.state` object is always the current underlying state values, and any Model instance that still represents an entry that exists in the store will return the correct values when you access its fields.  So, it's possible you may still have to be careful about sequencing update logic at times, but it's a lot simpler with 0.9 than it was with 0.8.

Introduction

Project Planning and Setup

UI Layout and Project Structure

Using Redux-ORM

Loading and Displaying Data

Connected Lists, Forms, and Performance

Form Change Handling, Data Editing, and Feature Reducers

Form Draft Data Management

Managing Modals and Context Menus

Wrapping Up

Typical Usage