Proposal: Allow Map and Set in the Redux state

[srmagura]

The "Best Practices" doc is quite clear about non-serializable values in the Redux state:

Avoid putting non-serializable values such as Promises, Symbols, Maps/Sets, functions, or class instances into the Redux store state or dispatched actions. This ensures that capabilities such as debugging via the Redux DevTools will work as expected. It also ensures that the UI will update as expected.

I am wondering if a special case could be made to allow Map and Set in the store.

I am looking for feedback on this idea. I would be happy to make PRs to RTK and other libraries to make it happen.

Benefits

• You could use Set instead of an array where appropriate. Set is much better than array when you are truly dealing with a set of elements (in the mathematical sense of the word "set"). Set can only ever contain an element once, so you don't have to worry about duplicates. And Set has O(1) membership checks, compared to O(N) with array.

• You could use Map instead of an object where appropriate. The benefit here is not as large as with Set, but Map does have ordered keys and is generally more performant. (Not sure if the performance boost still applies once Immer gets involved.)

• It would make it easier to move existing local state in Redux. Users may be using Map/Set with useState since React allows this. If you later need to move this state into Redux, you would have to refactor your code to use standard objects/arrays.

• It would be easier for newcomers. The ability to put Map/Set in Redux is one less "gotcha" that you have to learn.

Responses to likely counter-arguments

• "Map/Set are mutable." Not if you're using Immer with enableMapSet(), which auto-freezes these classes so that operations like mySet.add("test") throw an error if you are outside of an Immer producer. And I would argue that everyone should be using Immer (including using Immer indirectly through RTK).

• "Map/Set won't display correctly in Redux DevTools because they cannot be serialized." I think Redux DevTools could be easily updated to detect maps and sets and display them properly.

• "Map/Set won't work with time-travel debugging." I do not use time-travel debugging or know how exactly it works, so I can't comment on this one. That said, what percentage of Redux users actually use time-travel debugging? 5%?

• "Map/Set won't work with redux-persist/redux-saga/(insert library here)." Some libraries will probably work without any modifications, while others may require PRs or a bit of extra code in the consuming application. That said, I believe any code changes (whether to the library or consuming applications) would be straightforward. Consuming applications would require no code changes if the developers prefer to stick with normal arrays and objects.

• "You can always convert an array into a Set in a memoized selector." I'm not sure if anyone would make this argument but I'll address it for completeness.

  • This approach would only affect your components, so your actions and reducers could still not use Sets.
  • There is a performance penalty to converting from an array to a Set. Memoized selectors can help but this could be a serious performance hit for large sets that change frequently.

Drawbacks

• Allowing Map/Set would require PRs to RTK, Redux DevTools, and possibly other libraries. So there would be some work required to make this feature a reality.

• For RTK: Extra bundle size from Immer's enableMapSet plugin??? If it's an issue, this could remain an opt-in feature.

[markerikson]

I appreciate that you took the time to write this up, and also collect the most likely objections :)

Unfortunately, those objections still stand, particularly the ones related to mutation and serialization.

I'm actually working on an app right now that puts Maps and Sets into the Redux state ( https://github.com/RecordReplay/devtools ). For that matter, it also puts a bunch of class instances into the Redux state as well.

It does run.

But literally just today these persistence and serialization issues have caused a bunch of problems for me, and it's exactly these kinds of problems we're trying to guard against.

So no, this isn't a thing we will ever recommend or directly support in RTK.

[phryneas]

Just picking out two:

It would make it easier to move existing local state in Redux. Users may be using Map/Set with useState since React allows this. If you later need to move this state into Redux, you would have to refactor your code to use standard objects/arrays.

You should also not be using Set or Map in React's useState, as all the same problems, especially mutability, exist there, too.

Yes, they could theoretically be used with immer there, too, but "modifying" a Set or Map with immer means that a new one is created on every modification, which adds additional overhead.

Some libraries will probably work without any modifications, while others may require PRs or a bit of extra code in the consuming application. That said, I believe any code changes (whether to the library or consuming applications) would be straightforward. Consuming applications would require no code changes if the developers prefer to stick with normal arrays and objects.

Take redux-persist as the example of probably the most-used non-official Redux library: that is not a trivial change. Where before JSON.parse and JSON.serialize could be used, now all that would have to go from "valid JSON" to "some weird hand-written format" and lose interoperability with just about everything else. The rabbit hole does not end at those libraries, it goes deeper.

In the end: You can do in your app what you want. Call enableMapSet on initialization, override the isSerializable check, add a custom serializer to redux-persist, curse a bit about the devtools (in general they should kinda be able to handle Maps and Sets).

You are a single user, you can educate yourself, make a decision, live through it. That's fine. But we will not embrace it as an official recommendation - there is too much pain associated for unsuspecting users for usually very little gain.

[srmagura]

@markerikson @phryneas The experts have spoken 😉. Thanks for your feedback!!!

It seems like my proposal is not practical for the reasons you have described:

• Poor update performance with Immer
• The persistence/serialization issues Mark has experienced (even though he is surely following all the best practices)
• The rabbit hole of patching the many libraries in the Redux ecosystem

Again, I really appreciate the response.

Edit: for the record, I don't use Map / Set in my Redux stores, but I would like to if these issues didn't exist. Just annoying that these data structures don't feel like first-class citizens in the JS world.