5 ms·
Correct me if I am wrong, but the big advantage is that in most cases you no longer need to run a diff on the two values. You can do a naive comparison, and if
by lojack 11y ago
Correct me if I am wrong, but the big advantage is that in most cases you no longer need to run a diff on the two values. You can do a naive comparison, and if their references are different then you can assume the values have changed.
If you truly do need to run a diff, you're going to run into the exact same optimization problems with both immutable values and mutable values.
- deleted 11y ago[deleted]
- jlongster 11y agoYou can still optimize better with immutable types, because if you are diffing you are most likely diffing objects that share a lot of data, and for those subsections of the tree you can still do an `===` equality check and skip it during the diffing process.
- idibidiart 11y agoSince assignment of an object is by reference, if you say: var stateB = stateA, then both stateA and stateB now point to the same JS object. If you change stateB then stateA will be changed too since they both point to the same object So you would have to do: var stateB = JSON.parse(JSON.stringify(stateA)) to get a copy and then you can change stateB and it will not be equal to stateA. The problem is without use of actual "persistent data structures" (not "immutables" based on Object.freeze etc) the copy/clone operation is expensive. With persistent data structures as in ImmutableJS you get faster (O(1)?) copy. Therefore, building your state store on ImmutableJS and doing an explicit comparison (if you're using React) with shouldComponentUpdate by comparing 'prevState != curState' is the only thing you need, and I had seen benchmarks that show 35% increase in performance over not using ImmutableJS. Update: in response to the question about having a list of items and React invoking shouldComponentUpdate, that should not be the case if React stops comparing when the parent aka the list itself says that update should not happen. Does React in that case descend down the tree to compare the state of the list items? I suppose it would but there must be a way adound it. I heard about batchUpdate add-on in this context. Researching now!
- amelius 11y agoBut let's say the UI consists of a list of N text elements. That list is encoded as an immutable vector. When one of the elements changes, react will run through the complete list and call shouldComponentUpdate for each item (!) In contrast, with a fast "diff" operation, we could simply determine which of the elements in the state have changed, and this would be fast.
- deleted 11y ago[deleted]
- epmatsw 11y agoHow would you implement a fast diff that didn't involve looking at each text value anyways? Would there be a separate store in the structure that tracks changes, or something along those lines?
- amelius 11y agoYou can do this by skipping over shared sub structures, while comparing, for example.
- epmatsw 11y agoI don't see how that is related to immutability. Immutability gives you the ability to verify that it's unchanged in O(1), but it doesn't change your ability to do optimizations like that...
- amelius 11y agoWell, immutable data-structures use "structural sharing", internally. Search for it. For example, this image, [1], shows two data-structures (the green nodes), that internally share many nodes. Now, comparing those two structures can be done efficiently, because the shared parts don't need comparing. [1] http://eclipsesource.com/blogs/wp-content/uploads/2009/12/clojure-trees.png http://eclipsesource.com/blogs/wp-content/uploads/2009/12/cl... (a random image I found on the internet that illustrates my point)