Object.assign does not work well when you have classes. For one of my projects I came up with a small helper to clone class instances: https://caurea.org/2015/07/19/generic-immutable-objects-in-j.... In addition to cloning, it freezes the new object so accidental attempts to mutate it will throw an exception (in strict code).
Pros and Cons of using immutability with React.js
11–20 of 30 posts
Re: Pros and Cons of using immutability with React.js
#12For those looking for great Flux libraries with immutability at their core, I've been loving NuclearJS[0], which is built on top of ImmutableJS and untangles your stores by giving you a great kind of "functional lens" called Getters. One problem I have is that ImmutableJS[1] doesn't list the complexity of any of the operations in their documentation. So it can be hard to intuit the efficiency of given operations with…
We've started using Redux [1] lately, because we found some flaws in the original Flux architecture [2]. We also started using ImmutableJS together with Redux. Would you care to list any advantages of NuclearJS over Redux?
[1] http://gaearon.github.io/redux
[2] biggest flaw: if an action updates two different stores, and a component depends on both stores, the component will get rendered twice. Even worse, the first time it will get rendered with one store updated and the other one not updated, so possibly in an inconsistent state.
Re: Pros and Cons of using immutability with React.js
#13This week I learned to love the spread operator. const newState = {...state, ...objectWithNewValues}
Whoa, that works on objects/properties? I hadn't seen that before. That's nice.
Yes, here some simple examples:
(state, action) => ({...state, loading: true})
(state, {error}) => ({...state, error, loading: false})
(state, {result:{data}}) => ({...state, ...data, loading: false})Re: Pros and Cons of using immutability with React.js
#14For those looking for great Flux libraries with immutability at their core, I've been loving NuclearJS[0], which is built on top of ImmutableJS and untangles your stores by giving you a great kind of "functional lens" called Getters. One problem I have is that ImmutableJS[1] doesn't list the complexity of any of the operations in their documentation. So it can be hard to intuit the efficiency of given operations with…
If you want the getters functionality in redux, use reselect: https://github.com/faassen/reselect
At this point I really get the impression that redux has "won" now that flummox recommends using redux instead of flummox.
Flux libraries are small and simple enough that it probably won't hurt to use a non-mainstream flux library, but it's probably still best to use the same one everybody else is using.
Re: Pros and Cons of using immutability with React.js
#15This week I learned to love the spread operator. const newState = {...state, ...objectWithNewValues}
That's really cool. Worth noting that it's an ES7 proposal rather than part of ES6, so you get it with Babel but not native ES6, or e.g. TypeScript.
Re: Pros and Cons of using immutability with React.js
#16Re: Pros and Cons of using immutability with React.js
#17Immutability doesn't have to be a discipline. It is the default when working with ClojureScript!
Re: Pros and Cons of using immutability with React.js
#18The author's primary motivating example is the high cost of deep equality checks. I'm not sure how immutability helps with that; yes, if two variables are === then they havn't changed, but two objects can be !== but still value equal. So if you want to know if two objects are (value) equal, you'll still need to check.
Re: Pros and Cons of using immutability with React.js
#19The author's primary motivating example is the high cost of deep equality checks. I'm not sure how immutability helps with that; yes, if two variables are === then they havn't changed, but two objects can be !== but still value equal. So if you want to know if two objects are (value) equal, you'll still need to check.
The primary use case for checking equality in React is when you change one part of your application state and it triggers a rerender of a large React component tree. Since you probably only changed one small bit of the state (e.g. you created a new todo list item), you don't actually need to rerender unrelated components (e.g. the already-existing todo list items). Immutable data allows you to do cheap (constant time) reference equality checks, because the data objects representing the existing todo list items will be the exact same objects that they were previously.
In this fundamental React render flow, you probably won't need to worry about checking value equality between two different objects if you are using immutable data. Now, your application might have specific UI requirements that need to do value equality. As a random example, you might have a complex form, and you might want to know if, after the user changed several things, the form's data is different than it was at the beginning. In this case, you'll have to do a (more expensive) value equality check.
Re: Pros and Cons of using immutability with React.js
#20The author's primary motivating example is the high cost of deep equality checks. I'm not sure how immutability helps with that; yes, if two variables are === then they havn't changed, but two objects can be !== but still value equal. So if you want to know if two objects are (value) equal, you'll still need to check.
With React, the point is that by simply comparing the reference to immutable objects you can skip most unnecessary re-renders almost for free. Of course you'll still have some false positives (ie, the reference is different but the content is the same, and re-rendering wasn't necessary) but that's not a big penalty.