Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pros and Cons of using immutability with React.js

reactkungfu.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Pros and Cons of using immutability with React.js

#21

Post by chenglou »

rattray wrote: post #5

For 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…

Listing complexity doesn't really help here. There's a huge difference in practical complexity than the theoretical one. Saying that "insert" has log(n) complexity is misleading when you realize the branching factor is 32. Likewise, "compare" has log(n) or mostly constant complexity in most real-life settings where you're comparing against a value that was calculated from the one you're comparing against (so shares lots of subtrees by reference). You're not e.g. sending back a fresh new copy of the data from the server to compare against. Immutable-js _could_ put "it's linear theoretically but most of the time it's really almost constant time", but that doesn't help much either.

Is it blasphemous to say that looking at runtime complexity is gradually becoming more of a premature optimization (thanks to better hardware)? You can argue all day long that your js object has constant insertion time, but the underlying implementation makes it an order of magnitude slower than array for a limited number of fields. And if you accidentally trigger the hidden class deopt that turns it into a hash map that's another order of magnitude slower. No amount of ordinary complexity analysis will help you here. Vice-versa, when Babel gradually starts supporting constant lifting for collections (somehow), you can look at a piece of code in your editor, reason that a comparison is linear, but then have the transpiler lift it out (`const liftedA = []; function foo() {return liftedA;}` instead of `function foo() {return [];}`) and not realizing yourself that the comparison is actually constant time (reference comparison). And then, if you write some overly clever optimization for that piece of code yourself, you might ironically get worse perf because the transpiler can't lift the collection anymore.

That being said, Immutable-js uses the same concept and clojure's persistent data structures (exposed as mori for JS users). Here's a nice article on it: http://hypirion.com/musings/understanding-persistent-vector-...

Re: Pros and Cons of using immutability with React.js

#22

Post by davexunit »

chenglou wrote: post #21
rattray wrote: post #5

For 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…

Listing complexity doesn't really help here. There's a huge difference in practical complexity than the theoretical one. Saying that "insert" has log(n) complexity is misleading when you realize the branching factor is 32. Likewise, "compare" has log(n) or mostly constant complexity in most real-life settings where you're comparing against a value that was calculated from the one you're comparing against (so shares l…

>There's a huge difference in practical complexity than the theoretical one.

This resonates with me. I write a lot of Scheme, and often enough someone comes along saying that association lists (simple lists of pairs) are terrible because lookup time is linear and that I should be using hash tables. However, they don't realize that hash tables are only faster when the mapping is very large and come with a penalty of no longer having a persistent data structure.

Re: Pros and Cons of using immutability with React.js

#23

Post by munro »

Immutability for stateful things seems unintuitive at first, but reframed as the lack of mutability, it makes more since. We can easily add it.

    yourCar === neighboursCar; // false
    yourCarRepainted === yourCar; // false :(
In the article's examples, how does the program know which object is different? It's weaved into the language design that every object has an address. That means if we want to write code without mutability, the interpreter has no idea since mutability is always on, and can't protect from accidentally modifying intentionally stateless code.

Flip side, if immutability is the default, we can easily add state, since it's just a lack of an address. The address becomes part of the data structure, giving the coder more power, since it's not locked outside of the code. Think SQL! Or Haskell!

    var yourCar = {id: 'my_car', color: 'red'},
        neighboursCar = {id: 'neighbours_car', color: 'red'};
    
    function referenceEqual(a, b) { return valueEqual(a.id, b.id); }
    
    referenceEqual(yourCar, neighboursCar); // false :D
    var yourCarRepainted = Object.assign({}, yourCar, {color: 'red'});
    referenceEqual(yourCar, yourCarRepainted); // true :D
Notice we've now flipped the address into our data, and even the (===) operator in our hands. With JS, this will run slowly since it can't infer our immutability, but constants are coming!

Re: Pros and Cons of using immutability with React.js

#25

Post by rattray »

chenglou wrote: post #21
rattray wrote: post #5

For 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…

Listing complexity doesn't really help here. There's a huge difference in practical complexity than the theoretical one. Saying that "insert" has log(n) complexity is misleading when you realize the branching factor is 32. Likewise, "compare" has log(n) or mostly constant complexity in most real-life settings where you're comparing against a value that was calculated from the one you're comparing against (so shares l…

I found this an extremely helpful comment! Thanks very much, chenglou!

EDIT: Though, I personally think it actually would be pretty helpful if ImmutableJS put something like this in their docs: "it's linear theoretically but most of the time it's really almost constant time"

Re: Pros and Cons of using immutability with React.js

#27

Post by rattray »

danmaz74 wrote: post #12
rattray wrote: post #5

For 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…

The biggest gap I was previously aware of in Redux was the lack of getters, but as bryanlarsen points out in a sibling to your comment, that appears to be available in reselect: https://github.com/faassen/reselect (last time[0] I talked about Nuclear vs Redux here, reselect didn't have a readme). So I'll need to take some time to evaluate the options...

[0] https://news.ycombinator.com/item?id=9833058

Re: Pros and Cons of using immutability with React.js

#28

Post by dchest »

rattray wrote: post #5

For 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…

Hmm, reading docs:

Lists are immutable and fully persistent with O(log32 N) gets and sets, and O(1) push and pop.

Immutable Map is an unordered KeyedIterable of (key, value) pairs with O(log32 N) gets and O(log32 N) persistent sets.

A Collection of unique values with O(log32 N) adds and has.

etc.

Re: Pros and Cons of using immutability with React.js

#29

Post by stevebmark »

There is a lot of good information here, but being a stickler for detail, I found the frequent grammar errors distracting. It seems like with all the self-advertisement conversion signup forms, it would be helpful to have an editor, or a native speaker of the language it's written, go over it.

Re: Pros and Cons of using immutability with React.js

#30

Post by danmaz74 »

rattray wrote: post #27
danmaz74 wrote: post #12

Earlier quoted context omitted.

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…

The biggest gap I was previously aware of in Redux was the lack of getters, but as bryanlarsen points out in a sibling to your comment, that appears to be available in reselect: https://github.com/faassen/reselect (last time[0] I talked about Nuclear vs Redux here, reselect didn't have a readme). So I'll need to take some time to evaluate the options... [0] https://news.ycombinator.com/item?id=9833058

Thanks for the reply. The philosophy for Redux seems to keep the core as agnostic as possible, and that's why getters are outside of core. In part I like this, in part I don't - for sure it makes it difficult to evaluate it, as there are so many possibilities... I think I wouldn't mind some more convention over configuration.
Post reply on HN