Returning plain JS object from memoized selector using Immutable.js

Question

I'm working on a React + redux + Immutable.js + reselect application. I'm considering a design where I'm using Immutable.js in the reducers and sagas, but don't want to couple this library with the smart components, so my presentational part of the app as clean as possible.

According to redux documentation your selectors should always return Immutable object.

My idea is to compute derived state in reselect selector and return plain JS object. If I use memoized selector, new object won't be created on every call if underlaying part of redux state is the same, so my component won't be rerendered unless needed.

I know that I'll partially pay with composability, since the selector cannot be uses as an input for other Immutable.js-ready selectors, but I'll get much cleaner smart components.

Are the any other drawbacks of such solution?

Why does redux documentation so strongly encourages to push Immutable object to smart components?

Answer 1

Are the any other drawbacks of such solution?

toJS is an expensive operation, even if memoized. The argument is why toJS if you don't have to?

Why does redux documentation so strongly encourages to push Immutable object to smart components?

The aforementioned, plus it makes reasoning about the whole redux pipeline easier, i.e. any mutations (side effects/morphisms) to state are easier to wrap one's head around as there's a clear flow and point where changes occur.

With all that said, it comes down to preference and where one feels the bottlenecks/trade-offs in one's architecture are. If you feel having a clean separation outweighs the potential risks/caveats with having toJS in the selector, then that's the correct call for your architecture.

On a side note regarding loss of composability in the selector, you could always have two selectors, one that returns the immutable state--used for selector composition, and one that uses the immutable state selector and calls toJS, where appropriate.

Answer 2

Are the any other drawbacks of such solution?

toJS is expensive and also debugging the application becomes more complex.

Why does redux documentation so strongly encourages to push Immutable object to smart components?

1. Immutable objects are validated more deeper than plain Objects. In case of oldObject === newObject validation plain objects will be compared on a global level whereas oldImmutableObject === newImmutableObject is compared more deeper. This is more efficient on the render tree avoiding unnecessary updates on rendering React components.

2. Easy to modify objects with helper functions. get, set and more.

3. Unnecessary data copying is avoided.