new objects added via produce are not frozen

[vytautas-pranskunas-]

I am playing around with immer.js. I have added new object to draft in produce function. After receiving new state whole object is frozen except newly added child.

const nextState = produce({items: {}}, draftState => {
    draftState.items['test'] = { id: t, name: 'ITEM-NEW', value: 0 };
  });

Object.isFrozen(nextState.items.test) // false

Or

const nextState = produce({items: [] }, draftState => {
    draftState.items.push({ id: t, name: 'ITEM-NEW', value: 0 });
  });

Object.isFrozen(nextState.items[0]) // false

But

Object.isFrozen(nextState.items) // true

I think it should be frozen or?

[cyrus-za]

@vytautas-pranskunas- it does not seem like @mweststrate intends for this. See test at

immer/__tests__/frozen.js

Line 110 in a7a8cfa

it("a new object is added to a nested draft", () => {

I am still very new to Immer, so not sure as to why this is intended (likely performance issues, or the fact that the produce function might reference a closure when you add the new item to the draft and you might not want that referenced object to suddenly become frozen. Either way, this seems to be intended.

[vytautas-pranskunas-]

I see freeze benefits because less exp devs cannot change it directly same like immutablejs. If i add new object and it is not frozen then it can be changed directly not via immer. So where us immutability?

…

On Sat, May 11, 2019, 10:02 AM Pieter Venter ***@***.***> wrote: @vytautas-pranskunas- <https://github.com/vytautas-pranskunas-> it does not seem like @mweststrate <https://github.com/mweststrate> intends for this. See test at https://github.com/immerjs/immer/blob/a7a8cfab2e5b0ab0466cca51a003abb18bd68b01/__tests__/frozen.js#L110 I am still very new to Immer, so not sure as to why this is intended (likely performance issues, or the fact that the produce function might reference a closure when you add the new item to the draft and you might not want that referenced object to suddenly become frozen. Either way, this seems to be intended. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#363 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA54ZF2QW2OOXTGMTIGAI73PUZ4QRANCNFSM4HMHKW3Q> .

[cyrus-za]

I understand, but remember there is no guarantee that it is a new object. It could be referencing something from the parent scope. I suggest you call Object.freeze(newObj) before adding it to the draft. At least until @mweststrate or @aleclarson had time to respond

[vytautas-pranskunas-]

I know i can do thus but first thing this is costly operation and for prod is not required... Second thing i am doing generic thing and users should not be aware of object.freez 😉

…

On Sat, May 11, 2019, 1:01 PM Pieter Venter ***@***.***> wrote: I understand, but remember there is no guarantee that it is a new object. It could be referencing something from the parent scope. I suggest you call Object.freeze(newObj) before adding it to the draft. At least until @mweststrate <https://github.com/mweststrate> or @aleclarson <https://github.com/aleclarson> had time to respond — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#363 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA54ZF3JTKSALUA3XRGUH3TPU2RRHANCNFSM4HMHKW3Q> .

[aleclarson]

Duplicate of #260

For a workaround, see here: #260 (comment)

[vytautas-pranskunas-]

Ok so then explain me benefit of using immer versus plain object manipulation? Is that immer creates new object on each manioulation?

…

On Sat, May 11, 2019, 1:57 PM Alec Larson ***@***.***> wrote: Duplicate of #260 <#260> For a workaround, see here: #260 (comment) <#260 (comment)> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#363 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA54ZFZ27GHKBFDCQPTWXP3PU2YDNANCNFSM4HMHKW3Q> .

[mweststrate]

The point of this library is to make writing "updates" to immutable data structures easy. The point is not to make the data itself immutable (although it does make stuff mutated by producers immutable, in dev mode, as convenience for devs). if your goal is to make the data structures themselves immutable, you can use a library like deep-freeze, either on the entire tree, or just on the data passed in to producers, or create your own produce that calls immer produce first, and then applies deepFreeze to the result.

[vytautas-pranskunas-]

Then perf comparison of immutableJs is not totally correct because deepFreee will have perf impact and immutableJs does not freezing objects but does not allow you to muttate any data without creating new state. 2019-05-13, pr, 09:54 Michel Weststrate <notifications@github.com> rašė:

…

The point of this library is to make writing "updates" to immutable data structures easy. The point is not to make the data itself immutable (although it does make stuff mutated by users immutable, in dev mode, as convenience for devs). if your goal is to make the data structures themselves immutable, you can use a library like deep-freeze, either on the entire tree, or just on the data passed in to producers, or create your own produce that calls immer produce first, and then applies deepFreeze to the result. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#363 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA54ZFZZO4PE6LEJBV5YJNLPVENCLANCNFSM4HMHKW3Q> .

-- Pagarbiai, Vytautas Pranskunas