Pros and Cons of using immutability with React.js
reactkungfu.com
Pros and Cons of using immutability with React.js
1–10 of 30 posts
Re: Pros and Cons of using immutability with React.js
#2Very well written - great job!
Re: Pros and Cons of using immutability with React.js
#3There's a benefit to teasing apart two ideas here:
- writing functions that expect immutable data (you get referential transparency and value equality → a system that's easier to reason about) - using persistent data structures (makes it cheap and efficient to create new changes to your data over some messy Object.assign helpers)
Javascript doesn't promote applications written in that style though, so you're definitely going to want to use a library like Immutable.js everywhere for those kinds of guarantees.
Re: Pros and Cons of using immutability with React.js
#4> I’d recommend the immutable-js library for it. It has nice API and it comes from Facebook itself. Another option is the baobab library - but it works better when more ‘reactish’ ideas are present in your codebase, like global app state.
Another option is a library I wrote, react-cursor[1], which is basically sugar over the React immutability helpers[2] which the article mentioned. react-cursor has a couple advantages over immutable-js and baobab:
1/ simpler types: use regular react state with plain old js data structures, 2/ simpler implementation - about 100 lines of code and tiny api, 3/ super easy to integrate with your existing large codebase already using react state
[1] https://github.com/dustingetz/react-cursor [2] http://facebook.github.io/react/docs/update.html
Re: Pros and Cons of using immutability with React.js
#5For 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 without having read/grokked the 5k sloc of source.
Re: Pros and Cons of using immutability with React.js
#6Okay as far as it goes but it downplays some difficulties.
A con when updating tree structures is the need to replace all nodes along the path from the root, which is why functional languages sometimes use fancy data structures like lenses.
Graphs are a bit awkwardly represented (can't use regular pointers due to cycles).
Reference comparisons are fast for small nodes, but for something like a large list, it's often not enough to know it was touched. You need to compute the diff to make updates efficient, which often requires a linear scan or worse. Making this efficient for arbitrary list mutations is a fairly difficult problem.
Re: Pros and Cons of using immutability with React.js
#7This is a good overview article with lots of practical examples. One nit. These lines are written many times:
x == y; // true
x === y; // true
Re: Pros and Cons of using immutability with React.js
#8This week I learned to love the spread operator.
const newState = {...state, ...objectWithNewValues}Re: Pros and Cons of using immutability with React.js
#9This 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.
Re: Pros and Cons of using immutability with React.js
#10Okay as far as it goes but it downplays some difficulties. A con when updating tree structures is the need to replace all nodes along the path from the root, which is why functional languages sometimes use fancy data structures like lenses. Graphs are a bit awkwardly represented (can't use regular pointers due to cycles). Reference comparisons are fast for small nodes, but for something like a large list, it's often…
> fancy data structures like lenses
I think you mean zippers. I'm not sure if lenses can be called data structures. They are closer to Functors than say Linked Lists in nature (but I may be wrong here).