(For reference, I'm a Redux maintainer. We now recommend Immer as the best way to write immutable update logic in Redux apps, and use it in our Redux Starter kit package.)
Here's the current roadmap towards 1.0:
https://github.com/reduxjs/redux-starter-kit/issues/82
I just pushed out a breaking set of changes a few days ago, and will likely make one more set of breaking changes to `createSlice` in the near future. After that, I'm hoping the API will _mostly_ be good to go, and I can push it towards 1.0 in the very near future.
Do you know some reference that addresses this?
And if we're here an additional question: since our store data is currently composed of deep immutable JS data structures, do you know of a way to slowly migrate to Immer?
I've tried to move parts of the store to Immer, but since the root store obejcts are still Immutable js objects, this didn't go well.
All that's necessary is to do immutable updates of your data, by always making _copies_ of the data and modifying the copies (see [0] and [1] for discussions of immutable updates).
It doesn't matter whether the new object references were produced by manually creating copies ( `{...obj}`, `someArray.map()`, etc), by using Immutable.js's API, or Immer tracking the "mutations" via a proxy and creating the new references internally. As long as you have immutable updates and new references, shallow comparisons work fine.
So, there's nothing special you need to do to make Immer work with comparisons. You literally just use it as described in the docs.
Specifically for comparisons, `PureComponent` and `React.memo()` both do shallow comparisons of `props` by default.
Yes, the pervasiveness of Immutable.js's API is one of the reasons I've long suggested that folks avoid it [2]. I don't have any detailed suggestions for migrating, other than perhaps consistently using Reselect selectors to encapsulate reading values from the store and handling the Immutable.js -> `toJS()` conversion (which you should probably be doing anyway as a perf optimization, since that conversion is relatively "expensive"). That way, as you switch over chunks of reducer logic from Immutable.js to Immer, the code consuming those values _should_ still be getting POJOs out of the selectors, with no actual visible change.
[0] https://redux.js.org/recipes/structuring-reducers/immutable-...
[1] https://daveceddia.com/react-redux-immutability-guide/
[2] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...
We recently switched from using ImmutableJS in our Redux store to using ImmerJS.
We took the approach one reducer at a time. We have multiple reducers and we're using combineReducers (the ImmutableJS one until it was completely converted).
We had no issues whatsoever in the change. ImmutableJS doesn't care about plain JS objects (which is what ImmerJS reducers return) so everything worked as expected.
React's shallow comparison worked as expected since ImmerJS produces new objects on mutation (just like ImmutableJS).
Essentially: there is no case where ImmutableJS is needed. All functionality and benefits are available in ImmerJS which is a much easier to use library.
To do the migration, we literally just used the docs on the Github repo. This was back with version 1.0 or something and it wasn't documented very well but we were able to figure it out. The first code example is how to use it with Redux. Also the section on Currying is useful.
Edit to add: This is all within the context of web apps, specifically React apps with Redux. I'm sure there's probably some places where ImmutableJS is desirable, but I don't know of any.
Immerjs just improves the ergonomics updating a native nested structure in a way that the original contents are maintained as much as possible. Because js has dreadful support for equality checks, this definitely comes in useful.
With Immer and "hand-written" immutable updates, doing a `{...obj}` or `someArray.slice()` will do a "shallow" copy of the object. This is equivalent to what Immutable.js does in that it keeps all the fields pointing to the same references. However, the JS engine does have to do an O(n) processing of all the individual top-level keys, whereas Immutable.js's internal data structure is O(logN) or something like that. So, for _very_ large objects, it is faster for Immutable.js to make a copy than it is for plain JS data.
My take, however, is that
- Most apps will not be dealing with gigantic objects, so there's no perf benefit from using Immutable.js
- Immutable.js is a much larger dependency than Immer
- The fact that Immer works with POJOs _and_ gives you the ability to write trivial "mutative" syntax for updates is a huge improvement over Immutable.js's Java-inspired API
So, to me, the only hypothetical use case where Immutable.js would actually be worth it is if your app is consistently dealing with huge objects, _and_ there is truly serious overhead from copying them that needs to be optimized.