When producing the next state, all branches of the draft should be frozen

[zhangenming]

🐛 Bug Report

modifice orgin will affect im
modifice im will affect orgin

To Reproduce

      var origin = {
        a: {
          value: 'no',
        },
        b: {
          value: 'no',
        },
      }
      var im = produce(origin, origin=> {
        origin.a.value = 'im'
      })
      // origin.a.value = 'yes'
      // origin.a = 'yes'
      origin.b.value = 'yes' //modifice orgin will affect im
      // origin.b = 'yes'
      // origin = {}

      // im.a.value = 'yes'
      // im.a = 'yes'
      im.b.value = 'yes' //modifice im will affect orgin
      // im.b = 'yes'
      // im = {}

Expected behavior

I don't know if this is as expected
or it shuold not affect each other?

[mweststrate]

are you on the last immer version? If so, please provide a reproduction in a codesandbox.

[zhangenming]

yes, Didn't you succeed in reproducing it?
https://codesandbox.io/s/bold-greider-7f629

[mweststrate]

Thanks for the repro.

Note that this in principle not an Immer bug, as you are modifying an object that was created outside of immer, and which is never touched by immer, outside of immer again.

That being said, I think we should try to freeze the entire tree to avoid confusion in cases like these.

[zhangenming]

i have a immature idea
if we have a large obj , such as

var obj = {
a1:1,
a2:2,
a3:3,
...
a1000000:1000000
}

now, immer looks like it's going to copy the object all key again, like{...obj}, it's will slow
how about just like this:
var objProto = {_proto_:obj}
then, we can access property like objProto.a1,
and we can modify property like objProto.a1 = 2,( and we Not modify origin data obj )

[mweststrate]

This has been fixed in Immer 6 (?)

[aleclarson]

🎉 This issue has been resolved in version 7.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀