Comparing Redux data model with classic Object data model

Redux data model is surprisingly similar to the classic object oriented approach. Object programming is sometimes considered antithesis to the functional programming which is the base for the Redux data model. However object oriented programming and functional programming are much more orthogonal approaches. It’s true that OOP is normally connected with imperative approach but that is not the requirement and you can connect it with functional programming as well. The key difference of Functional-Object programming in contrast to Imperative-Object programming is that you cannot modify internal state of an object and such methods have to return new object instead.

E.g. in psedocode:

Imperative-Object programming:

class C {
  int value;
  constructor(int value) { this.value = value }
  method() { this.value = 5 }
}

Functional-Object programming:

class C {
  int value;
  constructor(int value) { this.value = value }
  method() { 
    return new C(5)
  }
}

However, let's go back to the Redux. We can compare those two data models as follows:

Object programming                  Redux programming
==================                  =================

class                               state shape

object (class instance)             JavaScript object of the
                                    defined shape without any methods.
                                    (Note that in other languages
                                    this is typically called dict,
                                    hash or map.)

to send a message to the object     dispatch an action

method                              reducer (or part of a reducer
                                    handling particular action type)

The interesting fact is that in Redux all your work with is a single class with a single instance which represents the whole application current state. So when you are “sending the message” a.k.a. dispatching an action, you don’t have to specify a receiver. Because it is always the one and only object.

Alternatively you might view slice as a aggregated object and slice shape as its class. From this point of view, you have even multiple classes and objects.

However it’s not a singleton from an OOP perspective because as you go from state to state you create new and new instances and throw away the old ones. In fact when creating the new state inside reducer you actually have for a short while two instances of the state: an old and a new one.