How to use immutable.js with RTK (redux toolkit)?

[Yohandah]

I'm migrating legacy Redux code to RTK.

With my legacy code base I was using Immutable.js (for immutability purposes), I don't need it anymore for the new code I'm gonna write, but I would like for the legacy code to keep working without touching it, and while using configureStore from RTK. But my apps throws :

Invariant failed: A state mutation was detected between dispatches, in the path 'app._values._tail.array.0._values._root.array.0.array.16._defaultValues.gcm.__hash'. This may cause incorrect behavior. (https://redux.js.org/style-guide/style-guide#do-not-mutate-state)

I get it, it's because I change the object instance, I can disable the error doing so :

immutableCheck: false,
serializableCheck: false,

but IMO it disables too much, I would like to keep these settings on, but for Immutable.js to bypass the immutability check.
I found this piece of outdated code that looks like what I'm trying to achieve

// Augment middleware to consider Immutable.JS iterables serializable
const isSerializable = (value) =>
  Iterable.isIterable(value) || isPlain(value)
const getEntries = (value) =>
  Iterable.isIterable(value) ? value.entries() : Object.entries(value)
const serializableMiddleware = createSerializableStateInvariantMiddleware({
  isSerializable: () => true // all values will be accepted
  isSerializable,
  getEntries,
})
const store = configureStore({
  reducer,
  middleware: [serializableMiddleware]
})

here https://github.com/reduxjs/redux-toolkit/pull/141/files but it's not working, Iterable is now Collection and has no isIterable function, I've tried isImmutable but it's not working either.

Now the file looks like this : https://github.com/reduxjs/redux-toolkit/blob/master/docs/api/otherExports.mdx, there's no trace of Immutable.js.

What can I do ?

cross-post https://stackoverflow.com/posts/76506718/edit

[EskiMojo14]

the serializableCheck and immutableCheck are two separate checks, and we want you to customise them using getDefaultMiddleware.

For example, something like the below (untested) code might work:

import { configureStore, isImmutableDefault, isPlain } from "@reduxjs/toolkit";
import { isImmutable } from "immutable";

const store = configureStore({
  reducer,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      immutableCheck: {
        isImmutable: (value) => isImmutable(value) || isImmutableDefault(value),
      },
      serializableCheck: {
        isSerializable: (value) => isImmutable(value) || isPlain(value),
        getEntries: (value) =>
          isImmutable(value) ? value.entries() : Object.entries(value),
      },
    }),
});

[Yohandah]

@EskiMojo14 Ohh my god thank you so much for your quick help ! It's working 🙏🏻 !
I did not look carefully enough to see we could pass these props with functions to check. Maybe this quick fix for Immutable could be added to the migration documentation idk.

[jdeniau]

Hi,

Immutablejs maintainer here 👋

I'm playing with RTK today in order to migrate a "legacy" redux stack to RTK.

I saw that redux-toolkit does use immer for state management and that is not gonna change, I understand totally as state management is complicated 😄

middleware configuration

I encountered the same warning in the console, and @EskiMojo14 trick seems to work.

From my first tests, it seems that the only configuration needed is the serializableCheck

export const store = configureStore({
  reducer: {
    counter: counterReducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      // does not seems needed
      // immutableCheck: {
      //   isImmutable: (value: any) =>
      //     isImmutable(value) || isImmutableDefault(value),
      // },

      // ignore error for immutable value
      serializableCheck: {
        isSerializable: (value: any) => isImmutable(value) || isPlain(value),
        getEntries: (value: any) =>
          isImmutable(value)
            ? value.entries()
            : Object.entries(value),
      },
    }),
})

There is a TypeScript issue on getEntries though that needs to return Array<[string, unknown]> and value.entries returns an iterator.
As I do not really know the purpose of getEntries, I do not know how to test what does work here.

As a matter of fact, I could expose a helper utility in immutable that helps user to configure the middleware.

tested cases

Full immutable state

Full immutable state seems to work fine with the immutable API.
You do need to return the new state, but it's a classic case with immutable:

- state.status = 'loading';
+ return state.set("status", "loading");

https://github.com/jdeniau/redux-toolkit-immutable/blob/test-immutable-state/src/features/counter/counterSlice.ts

object state with an immutable part

A more tricky state is an object state that does contain parts of immutable objects. It does seems to work too. The code is weirder thought as it does mix immer and immutable logic.

- state.status = 'loading';
+ state.immutable = state.immutable.set("state", "loading")

https://github.com/jdeniau/redux-toolkit-immutable/blob/test-internal-immutable/src/features/counter/counterSlice.ts

typescript issue

The main issue I faced is with Typescript. Despite the fact that runtime seems to work, I'm stuggled with TypeScript here:

If I have an immutable object, I got error because immer types seems to "convert" anything to global.Map or global.Set

With an object:

Property '[Symbol.toStringTag]' is missing in type 'MapOf' but required in type 'Map<any, unknown>'.ts(2741)
lib.es2015.symbol.wellknown.d.ts(137, 14): '[Symbol.toStringTag]' is declared here.

With a list:

Type 'ImmutableInnerState' is not assignable to type 'WritableDraft'.
Types of property 'list' are incompatible.
Type 'List' is missing the following properties from type 'Set': add, [Symbol.toStringTag]ts(2322)

It may be caused by Classes should be made draftable or not mutated (and complex object management).

I do not know how this issue can be solved, as everything I tested seems to work.

Do you think it's something related to redux-toolkit package, or immer itself ?

Further discussion

I read a lot of your updated documentation and some issues closed on users that would like to make immer optional.

As I said, I do understand fully your point: state management is hard, immutability is key in react, and immer does have an API that is close to the Javascript API.

But on the other hand, immutable was really used with redux (and is still really used : 16M download per week).

Do you see a path where we can make immutable "first-class" with redux ? maybe by allowing any other immutability library as a plugin or something like that ? It might accelerate the transition to RTK.

I am willing to help here if you think that it's doable.

I understand if you do not want to go in this path though. In this case I will try to make RTK working with immutable on my side by fixing the previous issues.

Thank you !

[markerikson]

Do you see a path where we can make immutable "first-class" with redux ?

Hi! Quick answer: No :) Per https://redux-toolkit.js.org/usage/immer-reducers#why-immer-is-built-in and https://redux.js.org/style-guide/#use-plain-javascript-objects-for-state , we've advised against use of Immutable.js for a while. Immer is smaller, simpler to use, and already integrated into RTK.

We do have a very WIP PR at #3074 that would potentially allow other Immer-equivalent libraries like mutative to be used instead (as they have claims of being even faster than Immer), but even that's low priority for us atm (and I don't think that would have any relevance for trying to integrate Immutable.js anyway).

The TS issues are very likely something on the Immer side - afraid I don't have any suggestions on that one.

[EskiMojo14]

with regards to getEntries, it looks like the type could be loosened to (value: any) => Iterable<[string, any]> and the source code would stay the same - but ultimately it's not that hard to do Array.from(value.entries()).

[EskiMojo14]

the immutableCheck config is for performance, mainly - it means that the middleware will treat any ImmutableJS instances as immutable and not try to track mutations to them.

[jdeniau]

Thank you both for your quick response and for your honesty 🙂

@EskiMojo14 thanks for the detail

@markerikson thanks for the link on the PR, I will try to look at it to see if a library that has not an API similar to immmer may work.

I don't think that would have any relevance for trying to integrate Immutable.js anyway

I do not agree with you here, it will be useful for immutable user that do not want to swap to another library, and immer tradeoff on complex objects makes it not that easy to adopt (in my case I do store API entities in redux store, I can not simply change that).

Redux TK seems to make redux use really easy, particularly with TS (and immutable was really bad with TS too, I'm putting some effort to make it better). But having to choose between immutable and RTK is too bad.

If there is a way to make the "plugin-like" API work with immutable, I will look forward to it, even if it's a long term PR 👌

In the meantime, I will try to make my store work with immer 🤞

Thank you both once again.