React-redux: Using custom objects in state

[jameslk]

It seems that custom objects and redux do not mix very well (as mentioned in rackt/redux/issues/454). The paradigm being that objects should be immutable, and changes are made by creating new object instances. For simple objects, this works fine, but once objects become more complicated it becomes more cumbersome (both to code and runtime efficiency-wise) to copy objects just to introduce a change. A common recommendation is to use Immutable.js, but that means using a third party library just to overcome this hindrance.

As I understand it, the point of enforcing immutability seems to be driven by the virtues of functional programming. But JavaScript is not a purely functional programming language. In fact, its design is built around mutability. With the introduction of the class syntax in ES6, this is even more the case. If the recommendation is to ditch native language features in favor of using third party libraries, you're fighting against the tide.

I would like to use custom objects and mutability, for example, to reap the benefits of encapsulation and information hiding, or using third party libraries which themselves create custom objects that should be part of the state of the application. This is very difficult to do with the notion that new objects need to be created each time. In fact, it becomes a performance nightmare when using third party libraries where I have to create new objects from that library each time to fit redux's paradigm.

The only solution I've come to, is to use version properties in the state when modifying custom objects to force redux to notice a change in the state. For example:

oldState.customObject.mutate();

state = {
customObject: oldState.customObject,
version: performance.now()
}

This is a hack at best, and is difficult to track given the opaqueness of custom objects (which is the point of encapsulation).

Is there a better solution here that resolves these concerns in redux?

[gaearon]

As I understand it, the point of enforcing immutability seems to be driven by the virtues of functional programming. But JavaScript is not a purely functional programming language. In fact, its design is built around mutability.

Redux's design is built around immutability. It is an explicit design choice we want to enforce. You can use something other than Redux (e.g. Flux) if this choice does not work well for you.

If the recommendation is to ditch native language features in favor of using third party libraries, you're fighting against the tide.

That JS currently doesn't provide value types doesn't mean it won't in the future. And ES6 array spread (as well as ES7 object spread proposal) make copying much less of a hassle in terms of syntax. In the meantime, yes, we're fighting against the tide, and judging by Redux (and React) popularity, quite successfully so.

In fact, it becomes a performance nightmare when using third party libraries where I have to create new objects from that library each time to fit redux's paradigm.

I'm not sure why you'd want to put third-party objects into Redux state. This isn't how it's meant to be used. If your domain calls for it (e.g. geomapping data provided by third party lib you can't change etc), then maybe Redux isn't a good fit for your app.