RFC: Make `immer` optional for `createReducer`

[neurosnap]

I think end-developers should be able to opt-out of immer behavior for createReducer and createSlice. There have been some questions raised recently after the 1.0 announcement that people have experienced performance issues when using createSlice because of immer.

For most use-cases, I think immer should be enabled. However, there are specific cases where I have needed to tune the performance of a set of reducers and needed to disable immer.

immer definitely provides a ton of value out-of-the-box and I think should be enabled by default. However, I also think this is one area where we can be a little more flexible and allow the option to disable it. createReducer is still extremely valuable even without immer and I think that is the main reason why I think it should be opt-out.

For createReducer we could provide an additional parameter that determines if immer is used:

 export function createReducer<
   S,
   CR extends CaseReducers<S, any> = CaseReducers<S, any>
- >(initialState: S, actionsMap: CR): Reducer<S> {
+ >(initialState: S, actionsMap: CR, useImmer: boolean = true): Reducer<S> {
   return function(state = initialState, action): S {
+    const caseReducer = actionsMap[action.type];
+    if (!useImmer) {
+      return caseReducer ? caseReducer(state, action) : state;
+    }
     // @ts-ignore createNextState() produces an Immutable<Draft<S>> rather
     // than an Immutable<S>, and TypeScript cannot find out how to reconcile
     // these two types.
     return createNextState(state, (draft: Draft<S>) => {
-     const caseReducer = actionsMap[action.type];
       return caseReducer ? caseReducer(draft, action) : undefined;
     });
   };
 }

Or we could create a separate function

export function createSimpleReducer<
  S,
  CR extends CaseReducers<S, any> = CaseReducers<S, any>
>(initialState: S, actionsMap: CR, useImmer: boolean = true): Reducer<S> {
  return function(state = initialState, action): S {
    const caseReducer = actionsMap[action.type];
    return caseReducer ? caseReducer(state, action) : state;
  };
}

I'm curious of everyone's thoughts. Can anyone else think of other ways to implement this feature?

I also think that createSlice should provide a property immer which gets passed to createReducer.

 const slice = createSlice({
   name: 'slice',
+  immer: false,
   // ...
 });

I could see this kind of change requiring some typings work before merging.

I'm willing to do the work to get a PR up for this, but I wanted to make sure it was something that the maintainers agree would be useful.

[markerikson]

Already asked in #183 , and no, I'm not planning to do this.

The point of RSK is to be opinionated. There's a million createReducer implementations out there that don't use Immer, including a copy-pasteable version from the Redux core docs. I don't see a need to make this configurable.

There's related discussion at #90 (comment) . Immer has a global setAutoFreeze() function that allows you to disable freezing if desired.

I can hypothetically imagine wanting to set that on a per-slice/reducer basis, and it would be technically possible if we accepted an option and then created a unique Immer() instance. But, again, I don't want to add that level of configuration at this point.

In general, my recommendation is to either not use RSK's functions here, or disable Immer's auto-freezing.

I'm really on the fence about using RSK because of this whole Immer thing. We don't use it or Immutable.js at my company and we have a ton of junior devs writing Redux code. They don't have any problem just using spread and destructure to write immutable state reducers.

The things being done in this library are very similar to what we have for our own in-house library but I wanted to switch to RSK because it's an official, well documented and maintained kit. If we use RSK and continue to write reducers that always return a whole new state object, Immer will be doing nothing for us but adding to our overhead and bundle size. Looking at Immer releases, I see their still making some major changes and fixing bugs every release so it's a little scary to me.

I guess I just wanted to add my voice to support for this option or something like it - maybe a separate non-Immer implementation of createReducer and createSlice.

[markerikson]

As I said earlier, the point of RTK is to be opinionated.

Sure, you can write nested immutable update logic by hand, the way you always have. In fact, you still can while using RTK, because you can return new state values from reducers.

But the point is you don't have to do it the hard way, and you shouldn't because it's error prone.

RTK currently uses Immer 4.x, as the 5.x releases don't add any features that we care about (specifically Map and Set support). That said, the fact that Immer is continuing to get worked on is a feature, not a bug - it means the lib is being well maintained.

If you skip the Immer aspect, RTK's createReducer is API-identical to the 6-line recipe we've shown in the docs for years:

function createReducer(initialState, handlers) {
  return function reducer(state = initialState, action) {
    if (handlers.hasOwnProperty(action.type)) {
      return handlers[action.type](state, action)
    } else {
      return state
    }
  }
}

But seriously, you should be using Immer, via createSlice. That will end up saving you a lot of hand-written code in the long run, and assuming the app continues to grow, odds are you'll have saved more lines of code than the actual size of Immer itself.

But the point is you don't have to do it the hard way, and you shouldn't because it's error prone.

I don't think that using spread/destructure is hard or error prone. As a matter of fact, picking out errors is easy because the pattern is very clear and when you don't follow it - it sticks out like a sore thumb in code reviews. We don't put a lot of logic in our reducers.

I honestly can't remember the last time we had an issue with reducers and we have dozens of teams using React/Redux.

createSlice...will end up saving you a lot of hand-written code in the long run...

Yep. I hear you - that's why our in-house kit already has something like createSlice without Immer and it works great. I like to keep things as simple as possible and not add the complexity of what amounts to training wheels in my opinion.

[markerikson]

I don't think that using spread/destructure is hard or error prone

Well, I'm genuinely glad your teams are doing well :) But having seen hundreds of Redux apps and helped thousands of users, I can confirm that accidental mutation is by far the most common mistake that users make, and I can also confirm just from my own experience that writing manual immutable update logic is a royal pain.

I don't ever want to have to do that again, I don't want our users to keep having to deal with that, and the size and abstraction Immer adds are totally worth it for the way it makes the rest of my code simpler.

We don't put a lot of logic in our reducers.

Note that this doesn't actually make things better or easier. If you're doing something like generating a new array outside of Redux in a component, and your reducer is just return action.payload, you still have to follow the rules of immutable updates. It's just not as obvious that you are supposed to be doing things immutably.

That's one of the reasons why the new Style Guide page specifically recommends that you should put as much logic as possible in reducers. It helps remind you that you should be following the rules of reducers like immutable updates, and if you're using RTK, you get the benefit of Immer for doing those updates.

[phryneas]

To add to this:

I don't think that using spread/destructure is hard or error prone.

immer does not only protect you from accidental modification in the reducer, but also from accidental mutation during render (and everywhere else).
If you had to search once for a bug where someone accidentally modified a value during render, you know that this can take many hours to find.

And yes, you might catch those in code reviews, but that code review is bound to happen when code is submitted. Most likely someone already spent hours chasing down some bug somewhere before that review. That a bug is caught doesn't mean that it didn't waste quite a few developer hours beforehand.

Also, as Mark already said: The bundle size of immer is smaller than the amount of code that immer saves you in almost every project that is large enough to worry about bundle size.

Hmmm, well you guys make some good points and even though we don't generally have problems with the things you're describing, it might not be bad to protect against them anyway.

Maybe there are problems that haven't even caught yet that can be fixed.

Most likely someone already spent hours chasing down some bug somewhere before that review.

In 2 years of using Redux I think this happened to us once or twice. They would tell me. I'm not saying it's not a problem ever and it's certainly not a fun bug to deal with, but the main thing I'm afraid of is that we trade that relative safety for new problems. I'd hate to recommend a pattern switch and then have it cause more problems than it solves. So, I'm just reading through the issues here and on Immer to see what people are going through and as far as I can see, it's not all risk free. (I'm a little nervous that there's no redux-persist guidance because that is one thing we have spent hours perfecting in our current setup. I saw the issue where the one commenter said they solved it so maybe it will just work out.)

At this point I guess I'll setup a trial project using RTK and see what happens, discuss with my peers and so forth...

Thank you so much for your detailed and thoughtful replies!

[phryneas]

If you notice any bumps on the road, make sure to open a ticket.
We are committed to make this as good as possible!

[markerikson]

@waynebloss : yeah, while I haven't ever used redux-persist myself, the only real point of concern here should be that apparently it tries to pass some non-serializable values in a couple actions, and it looks like that can be handled by telling the serializability check middleware to ignore those.

There's no "guidance" on using that in the docs, simply because it's a purely optional addon that isn't related to the Redux core or RTK at all. I could see us possibly adding a new core docs page on "Store Persistence" at some point, but that's about as far as I'd go.

[neurosnap]

I wouldn't add immer just to protect against unintentional mutation. There are other libraries that do that better without the performance overhead in production: https://github.com/buunguyen/redux-freeze

There is performance overhead with immer but for most applications it won't be noticeable.

I do think making immer not an option is a weird way to be opinionated, considering createSlice and the other aspects of this library are still useful without immer. The typing alone on createSlice is non-trivial to re-implement successfully. But this is the maintainers' prerogative and I support their decision.

@markerikson Well since we're here - what do you personally do for persisting a slice of state if you've never used redux-persist? We use it pretty heavily. Almost every app we create has some sort of frontend-only preferences/cache/etc that we want to store on the client...

(I actually checked how widely used redux-persist is just now and I was surprised to see that it's not that big - only about 360k weekly downloads compared to about 3 and 4 million for react-redux and redux. Maybe we need an update on how we do certain things.)

[markerikson]

Another reason to not bother making Immer optional atm is that we still don't have tree-shaking working for RTK, due to other dependencies: #78 .

So, if you use RTK, right now you're getting Immer whether you use createSlice or not, and would still do so even if createSlice had some option to not call Immer internally. For that matter, even if tree-shaking worked right, we've already had to do some ridiculous build shenanigans just to get redux-immutable-state-invariant to get left out of prod bundles. I don't even want to know how complicated it would get to try getting Immer to drop out conditionally.

(I'd really like to improve the tree-shaking behavior, but my priority atm is rewriting the Redux core docs, and no one has jumped in and tried to fix the build behavior.)

Folks are always welcome to fork the lib and do whatever they want with it, but given that I'm the maintainer, I'm the one setting the vision and what I want in the lib.

@waynebloss : I've never had to bother with store persistence, or routing for that matter. The apps I've worked on have been true "single-page" apps - ie, desktop-like apps that just happen to live in a browser.

[phryneas]

I wouldn't add immer just to protect against unintentional mutation. There are other libraries that do that better without the performance overhead in production: https://github.com/buunguyen/redux-freeze

This is a little bit of a rant, and even though it was triggered by you, it's more of a "we really have to have this written here" thing, so please don't take it as an attack 😄

If anyone has performance problems, immer is probably the last place to look

First about the comparison with deep-freeze:
Deep-freeze is about multitudes slower than immer to prevent unintentional modification (give the performance tests a try).
But as you already noticed, redux-freeze doesn't do that in production. immer doesn't as well.

So, aside from the performance impact of preventing mutation, there's one other point where immer can have a performance impact:
In the reducer. And only there. And sorry, but I don't believe that it plays a role if your reducer takes 0.1ms or 0.3ms. The stuff that comes after that takes so much more time and has so much more space for optimization.

• subscribing to the store from more components: if react rerenders too much of your application
• subscribing to less: if too many selectors are called on every store modification (or memoizing these)
• rendering less components: by using virtualized lists
• cleaning up your render functions: memoizing a single slow loop will have more impact on your application than swapping five libraries
• dispatching less actions and moving stuff out of global store: redux should not be used for forms, generally a lot of state should be moved into local state

If you have done all that and still suspect immer of "slowing down" your application, you might be one of those rare cases that has deeply-nested lists with tens of thousands of object in the store. Then removing immer isn't going to save you, because even vanilla js will be slow for you - you're gonna have to go the immutable.js route then, I'm sorry.

There is performance overhead with immer but for most applications it won't be noticeable.

Yup, just had to say the same thing with a lot more words for everyone to read 🤣

I do think making immer not an option is a weird way to be opinionated, considering createSlice and the other aspects of this library are still useful without immer. The typing alone on createSlice is non-trivial to re-implement successfully. But this is the maintainers' prerogative and I support their decision.

It would duplicate a lot of the code and the types of RTK (which would be a chore to maintain) and it would signal that we think that using Redux without immer is a good idea - which I would not ever recommend if the option of immer were in the room. Sure, there may be some extreme edge cases (where you would need something like immutable due to very big data structures) but the people that need these know it themselves.
In the end everything we put in this library is a recommendation to the ecosystem, and just writing in the docs "we put this here, but we really don't recommend that" is not an option, as too many people are just not reading the docs of anything.