Should not create a new object if the values are the same

I’m not sure if this is a bug or if I’m misunderstanding how this is supposed to work.

I assumed in the following example one and two would be the same object.

const obj = { foo: 0 };
const one = immutable(obj).set('foo', 'bar').value();
// { foo: 'bar' };
const two = immutable(one).set('foo', 'bar').value();
// { foo: 'bar' };
one === two
// false

[mariocasciaro]

Thanks for the more detailed description. I get it now and it makes sense. We’ll track this as an enhancement as it’s going to change the current behaviour of a few methods. Thanks for reporting Luke.

[Prinzhorn]

Was looking through the code and came to the conclusion that it is non-trivial at least for someone not comfortable with the code base. The problem is that the code works top-down and clones all objects along the path, but only at the very end inside changeCallback do we know if that was actually needed. At this point we could return the original thing, but still wasted time on all the cloning.

So how do we peek at the bottom to see if it would be a noop without duplicating most of the walking-logic? Or how do we delay/schedule the cloning until that point?