baobab icon indicating copy to clipboard operation
baobab copied to clipboard

question on immutable in production

Open shenbin04 opened this issue 7 years ago • 6 comments

in the readme regarding immutable, it reads

immutable boolean [true]: should the tree's data be immutable? Note that immutability is performed through Object.freeze and should be disabled in production for performance reasons.

What does this mean by should be disabled in production? Do we need to do anything specifically for production?

Thanks

shenbin04 avatar Feb 22 '17 19:02 shenbin04

This means that if you developed with immutable set to true, there is no danger to switch to false when in production (unless you do really strange things with your code) to increase performance for your users.

Yomguithereal avatar Feb 22 '17 20:02 Yomguithereal

@Yomguithereal thanks. So here is the follow up from my understanding:

  1. what baobab does is preventing other calls from mutating the object get from baobab tree directly via freezing.
  2. if I use baobab set api to make the changes, baobab takes care of immutable change so that it complies with the policy.

Essentially, I should not mutate the data get from baobab tree directly, rather use update api provided by baobab. Correct?

Thanks.

shenbin04 avatar Feb 23 '17 19:02 shenbin04

Essentially, I should not mutate the data get from baobab tree directly, rather use update api provided by baobab. Correct?

That's correct. The fact is if you try to mutate the objects given by the tree with immutable on it won't work anyway since the objects are frozen. But since it has a cost to freeze them, you can disable this in production because you don't need the "safeguards".

Yomguithereal avatar Feb 23 '17 22:02 Yomguithereal

@Yomguithereal Thanks. Another followup question:

    const tree = new Baobab({ hello: { world: 123 }, apple: { pie: 456} });
    const initialState = tree.get();
    tree.set('hello', { world: 123 });
    console.log(initialState === tree.get());
    console.log(initialState.hello === tree.get('hello'));
    console.log(initialState.apple === tree.get('apple'));

For the sample code above, I tried to set the value of tree using the same equal value. I got logs of false, false, true. Seems baobab is swapping the reference even if the value itself is equal. I'm trying to integrate this into react pure rendering, so optimally I will expect the reference is unchanged if the value itself remains the same.

Is this expected behavior of baobab or we didn't take care of this case? Thanks.

shenbin04 avatar Feb 24 '17 14:02 shenbin04

a followup finding: if I use tree.set(['hello', 'world'], 123);, the result will be true, true, true

shenbin04 avatar Feb 24 '17 14:02 shenbin04

Yes, this behavior is to be expected because Baobab cannot tell whether your { world: 123 } values are the same without performing costly diff operations. So, whenever possible, i.e. with scalar values, the tree can know if the update is a no-op. But in some other cases, it won't compute the differences for performance reasons.

Yomguithereal avatar Feb 24 '17 14:02 Yomguithereal