Practical Redux, Part 1: Redux-ORM Basics · Mark’s Dev Blog

  • Overall, I highly recommend the use of Redux-ORM in any Redux app that needs to handle normalized nested/relational data .
  • Once you’ve defined your models, you need to create an instance of the Redux-ORM Schema class, and pass the model classes to its register method.
  • It helps solve a number of use cases that are common to many Redux applications, particularly related to managing normalized relational data in your store.
  • In Part 2, we’ll look at specific concepts you should know when using Redux-ORM, and some of the ways I use it in my own application .
  • The majority of my reducer logic is more generic and not class-specific, so I opted instead to write my own slice reducer for this data and just use Redux-ORM as a tool to help with that.

Over the last year, I’ve become a very big fan of a library called Redux-ORM, by Tommi Kaikkonen. It helps solve a number of use cases that are common to many Redux applications, particularly related to managing normalized relational data in your store. I’ve used it heavily in my own application, and have come up with some useful techniques and approaches for using it. Hopefully you’ll find them useful in your own application as well.

@ReactNext: Have you heard of #Redux-ORM? Here’s a nice explanation by @acemarke #reactjs #redux

Useful techniques for using Redux-ORM to help manage your normalized state, part 1:

Redux-ORM use cases and basic usage

Over the last year, I’ve become a very big fan of a library called Redux-ORM, by Tommi Kaikkonen. It helps solve a number of use cases that are common to many Redux applications, particularly related to managing normalized relational data in your store. I’ve used it heavily in my own application, and have come up with some useful techniques and approaches for using it. Hopefully you’ll find them useful in your own application as well.

This first post will cover reasons why you might want to use Redux-ORM, and the basics of using it. In Part 2, we’ll look at specific concepts you should know when using Redux-ORM, and some of the ways I use it in my own application.

Client-side applications frequently need to deal with data that is nested or relational in nature. The standard advice for a Redux application is to store this data in a “normalized” form. For a Redux app, that means organizing part of your store to look like a set of database tables. Each type of item that you want to store gets an object that is used as a lookup table by mapping item IDs to item entries. Since objects don’t have a real sense of order, arrays of item IDs are stored to indicate ordering.

Because data is often received from the server in nested form, it needs to be transformed into a normalized form to be properly added to the store. The typical approach is to use the Normalizr library for this. You can define schema objects and how they relate, pass the root schema and some nested data to Normalizr, and it gives you back a normalized version of the data suitable for merging into your state.

However, Normalizr is really only intended for one-time processing of incoming data. It doesn’t provide tools for dealing with normalized data once it’s in your store. For example, it doesn’t include a way to denormalize data and look up related items based on IDs, nor does it help with applying updates to that data. There are a couple of other libraries that can help, such as Denormalizr, but there’s a definite need for something that can make these steps easier to deal with.

Fortunately, such a tool exists: Redux-ORM. Let’s look at how it’s used, and how it can make it easier to manage normalized data within the store.

Redux-ORM comes with excellent documentation. The main Redux-ORM README, Redux-ORM Primer tutorial, and the API documentation cover the basics very well, but here’s a quick recap.

folder in your project

section to the class itself that uses Redux-ORM’s relational operators to define what relations this class has:

These definitions do not actually need to declare what specific attributes each class has – just the relations to other classes.

method. This Schema instance will be a singleton in your application:

). That approach looks roughly like this:

I personally have taken a somewhat different approach. The majority of my reducer logic is more generic and not class-specific, so I opted instead to write my own slice reducer for this data and just use Redux-ORM as a tool to help with that. The basic approach looks like this:

functions:

There’s been numerous addon libraries people have built that try to put some kind of OOP layer on top of Redux, as demonstrated by the “Variations” page in my Redux addons catalog. I’ve frequently pointed out that Redux is primarily focused on Functional Programming principles, and that OOP wrappers over Redux aren’t idiomatic. So, given that I usually advise against using those sorts of libraries, you might ask why I encourage the use of Redux-ORM. What makes it different from other libraries like Jumpsuit or Radical?

Most of the OOP wrappers I’ve seen try to abstract things away by defining action creators as class methods, and often wind up ignoring the idea of multiple reducers being able to respond to a given action (or even making it impossible). They treat Redux as something that needs to be hidden, and end up throwing away many of the concepts that make Redux attractive.

On the other hand, Redux-ORM doesn’t try to hide Redux. It doesn’t pretend that action constants don’t exist, or that actions and reducers are always a 1:1 correspondence. It ultimately just provides an abstraction layer over something you would otherwise would have written yourself: CRUD operations for normalized data. It enables me to think a little less about “What specific steps do I need to follow to update or retrieve this data properly?”, and a little more about handling my data at a conceptual level.

Redux-ORM has become a vital part of my toolkit for writing Redux apps. The data I’m working with is very nested and relational, and Redux-ORM is a perfect fit for my use cases. Although it’s not yet marked as version 1.0, the API has remained consistent and stable since its inception, and Tommi Kaikkonen has been extremely responsive to issues I’ve filed. The fact that the library actually comes with real meaningful documentation (both tutorials and API docs) is a huge plus as well.

Overall, I highly recommend the use of Redux-ORM in any Redux app that needs to handle normalized nested/relational data. It won’t magically keep you from having to think about managing that data, but it will make it easier for you to deal with.

Practical Redux, Part 1: Redux-ORM Basics · Mark’s Dev Blog