Open in CodeSandboxWeb Editor |VS Code |VS Code Insiders

This pull request is automatically built and testable inCodeSandbox.

To see build info of the built libraries, clickhere or the icon next to each commit SHA.

Latest deployment of this branch, based on commit0888fde:

hi@phryneas,

I will add support for return values tomutative. But from the user's point of view, we should suggest always returning the draft itself or no value at all, not only does it maintain optimal performance (no extra performance wasted traversing unpredictable return values), but it also maintains the full mutation feature.

Hi@unadlib! That's great news!
Inwriting reducers withimmer (which we might need to rename to "writing mutable immutable reducers" or something like that), we generally recommend changing the existing state - but there are cases where the user might want to return something completely different.

Most common cases would be:

• replacing the full state with a completely new object (e.g. resetting state or taking a big chunk of data that came in, for example from an api call)
• the user wants to optimize things by hand
• they are just migrating over old Redux code that is not doing mutable updates yet.

From our perspective it would be fine if the rule were "if the user returns a value and that value is not the draft, just return that whole new value without traversing and touching it in any way", but I'm not sure if there are additional things that you have to do and cannot skip.

Hi@unadlib! That's great news! Inwriting reducers withimmer (which we might need to rename to "writing mutable immutable reducers" or something like that), we generally recommend changing the existing state - but there are cases where the user might want to return something completely different.

Most common cases would be:

• replacing the full state with a completely new object (e.g. resetting state or taking a big chunk of data that came in, for example from an api call)
• the user wants to optimize things by hand
• they are just migrating over old Redux code that is not doing mutable updates yet.

From our perspective it would be fine if the rule were "if the user returns a value and that value is not the draft, just return that whole new value without traversing and touching it in any way", but I'm not sure if there are additional things that you have to do and cannot skip.

Cool proposal. Since the user may refer to the draft in the return of a completely new object, I will use the optionstrict, which we will suggest the user enablestrict in development mode and disablestrict in production mode. This will ensure safe returns and also keep good performance in the production build.

If the return value is mixed drafts orundefined, then usesafeReturn() wrapper.

@phryneas@markerikson Mutative v0.3.2 already supports returning values in the draft functions. It is already fully compliant withproduce interface inredux-toolkit and maintains good performance.

@unadlib : nice!

One other question that came up is that we use several of Immer's utilities likeisDraft andisDraftable, in order to check whether it's safe to pass certain values intoproduce().

Doesmutative have anything like those?

@unadlib : nice!

One other question that came up is that we use several of Immer's utilities likeisDraft andisDraftable, in order to check whether it's safe to pass certain values intoproduce().

Doesmutative have anything like those?

@markerikson Yes, Mutative also providesisDraft() andisDraftable().

I rebased this branch againstv2.0-integration.

Also, for kicks, I tried swapping all our usages of Immer to use Mutative instead. Unfortunately, there's several critical test failures, including basiccreateReducer behavior. Looks like it's hitting aCannot perform 'has' on a proxy that has been revoked error.

https://github.com/reduxjs/redux-toolkit/tree/feature/try-mutative

I rebased this branch againstv2.0-integration.

Also, for kicks, I tried swapping all our usages of Immer to use Mutative instead. Unfortunately, there's several critical test failures, including basiccreateReducer behavior. Looks like it's hitting aCannot perform 'has' on a proxy that has been revoked error.

https://github.com/reduxjs/redux-toolkit/tree/feature/try-mutative

hi,@markerikson, I will debug it later. Overall, regarding the integration with Reducer, Immer and Mutative are not exactly equivalent, Mutative supports more options.

I rebased this branch againstv2.0-integration.

Also, for kicks, I tried swapping all our usages of Immer to use Mutative instead. Unfortunately, there's several critical test failures, including basiccreateReducer behavior. Looks like it's hitting aCannot perform 'has' on a proxy that has been revoked error.

https://github.com/reduxjs/redux-toolkit/tree/feature/try-mutative

For good performance, Mutative does not traverse mixed draft return values by default. When the return value is mixed with drafts, you can usesafeReturn().

Mutative docs:

We recommend to enable strict in development mode and disable strict in production mode. This will ensure safe returns and also keep good performance in the production build. If the return value is mixed drafts or undefined, then usesafeReturn().

You can fix tests like this,

https://github.com/reduxjs/redux-toolkit/blob/feature/try-mutative/packages/toolkit/src/tests/createReducer.test.ts#L174

- return state.concat({ ...newTodo, completed: false })+ return safeReturn(state.concat({ ...newTodo, completed: false }))

https://github.com/reduxjs/redux-toolkit/blob/feature/try-mutative/packages/toolkit/src/tests/createReducer.test.ts#L181

- return state.map((todo, i) => {+ return safeReturn(state.map((todo, i) => {

Hmm. That definitely makes it harder to usemutative as a drop-in replacement, because we don't know ahead of time what users are going to do in their reducers.

Ithink the right answer here is that we'd need to inject a wrapper that usessafeReturn, something like:

constcreateReducerWithMutative=buildCreateReducer({createNextState:(state,recipe)=>{returncreate(state,(draft)=>{returnsafeReturn(recipe(draft))})},  isDraft,  isDraftable})

Hmm. That definitely makes it harder to usemutative as a drop-in replacement, because we don't know ahead of time what users are going to do in their reducers.

Ithink the right answer here is that we'd need to inject a wrapper that usessafeReturn, something like:

constcreateReducerWithMutative=buildCreateReducer({createNextState:(state,recipe)=>{returncreate(state,(draft)=>{returnsafeReturn(recipe(draft))})},  isDraft,  isDraftable})

When the user usescreateReducerWithImmer, if the reducer wants to return the valueundefined, the reducer will have to return return Immer'snothing, and this implicit rule is similar to the case.

I also agree with you. WhethercreateReducerWithMutative returnsundefined explicitly or not is left up to the user, like this.

constcreateReducerWithMutative=buildCreateReducer({createNextState:(state,recipe)=>{returncreate(state,(draft)=>{constvalue=recipe(draft);returnvalue===undefined ?value :safeReturn(value);})},  isDraft,  isDraftable})

@markerikson I have refactored the implementation of the return value, once you upgrade to mutative v0.5.0, you will migrate Immer to Mutative smoothly, the relevant tests have passed.

The details are atunadlib/mutative#9

BTW, I tested the Immer v10 branch. Mutative is still more than 15x faster than Immer.

Hi, I'm the author ofstructurajs. Thanks for this pull request!

After some work I think I finally managed to make the library fully compatible with redux toolkit

As an example I did setup atry-structura branch which passes all of the tests contained into the packages/toolkit folder

Note that in this example branch I removed Immer completely, and I put all of my exports inside theexports.ts file

Also, I called enableAutoFreeze and enableStandardPatches to make all of the tests pass, but they are not always necessary and could be disabled to gain some performance:

• structura does not allow the produced state to be modified (at compile time via typescript), so relying on object freeze could be a bit redundant
• structura by default does not use standard json patches, but a proprietary format based on linked lists which is slightly faster; you probably don't need standard json patches unless you have to manipulate them with another library

If you see any problem or if you need help with something let me know!@phryneas@markerikson

@giusepperaso : thanks for working on that!

FWIW we reallydo want freezing in place, because wewant users to see errors at runtime if they attempt to mutate outside of a reducer. (Not everyone uses TS!)

is it worth making a configurable version of createDraftSafeSelector too? that currently uses immer's isDraft() and current()

✅ Deploy Preview forredux-starter-kit-docs ready!

Name	Link
🔨 Latest commit	0888fde
🔍 Latest deploy log	https://app.netlify.com/sites/redux-starter-kit-docs/deploys/651b2b31e7e2f100084383b4
😎 Deploy Preview	https://deploy-preview-3074--redux-starter-kit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to yourNetlify site configuration.

Found another similar lib:https://github.com/tnfe/limu

Hi, I'm not sure if there are any next steps planned for this proposal.

Currently, the performance test information related to Immer and Mutative is as follows:

• Use mutative instead of immer instantdb/instant#243
• Improve sorted entity adapter sorting performance #4361 (comment)
• https://mutative.js.org/docs/getting-started/performance/

Perhaps performance improvement is not a high priority for theredux-toolkit. So maybe I could provide an additional Mutative lib based on theredux-toolkit?

But, if there are further plans for this proposal, I would be very happy to participate.

@unadlib it's still an idea I'm interested in conceptually, but it's not on our roadmap to work on this any time soon. (I haven't had time to work on much RTK stuff lately, and when I do my focus will be on RTK Query features.)