5 ms·
With immutable objects, you can compare them (obj1 === obj2) and assume that if they're the same, none of the properties have changed. You don't have that sort
by eyko 9y ago
With immutable objects, you can compare them (obj1 === obj2) and assume that if they're the same, none of the properties have changed. You don't have that sort of guarantee with normal JavaScript objects, so you need to do a deep comparison.
If your component's state and props are immutable objects, then shouldComponentUpdate becomes a much easier problem to solve.
- BigJono 9y agoThat's not what GP was saying. The standard, non-library way of handling state in React is to use plain old mutable Javascript objects, and just pretend they're immutable (i.e never perform any mutable operations on them). The popular claim is that Immutable "enforces" immutability, leading to less "accidental mutation" bugs. (A claim which is bogus IMO. 0 !< 0)
- acemarke 9y agoNo, I'd say it's a _fairly_ valid claim. You have to interact with Immutable.js objects using its API, and every update API call returns a new instance. So, it _does_ generally enforce immutability. As far as I know, the only way to accidentally mutate stuff with Immutable.js is if you insert plain JS objects inside an Immutable.js object, and possibly also use one of its "update this using a callback function" methods and misuse things inside the callback.
- BigJono 9y agoThe bogus claim is that it leads to less bugs, not that it enforces immutability. It very obviously does that.