Comment by davedx | Hacker News Reader

Comment by davedx | Hacker News Reader

The main issue I've had using immutablejs with Redux is debugging. Whereas previously I could simply mouse-over a data structure when I hit a breakpoint (or crash), I now have to do a REPL dance to see what's in any of my data structures.

I also find myself often having to do trial and error stuff to fix my code (also while in a paused state in the console). I mean it's pretty nice that you can actually do this, don't get me wrong. But overall, I am slower and less productive with immutablejs than I am with vanilla JS / JSON objects.

It's a trade off people really should keep in mind before pulling the trigger on immutable data structures. Sure, you get that performance boost, but do you actually need it? Are your React views really so slow (or are you running on slow embedded hardware like I am)? Or are you just drinking the kool aid because immutable data is hot right now?

You get runtime perf improvements in certain cases, at the cost of opaqueness, productivity and complexity. Make sure it is worth it.

Hi, shameless plug: another (typed) immutable data structure library, https://github.com/gcanti/tcomb. Main features:

- works with regular objects and arrays - runtime type checks - easy debugging with Chrome DevTools - immutability and immutability helpers - runtime type introspection - easy JSON serialization / deseralization - pattern matching

Also https://github.com/gcanti/redux-tcomb (Immutable and type-checked state and actions for Redux)

I wouldn't call it an immutable data structure library. As far as I see, it does not implement any data structures.

This looks like a nice alternative to seamless-immutable though.

The solution to this and similar problems is to define more protocols like the iteration protocol [1], but for showing objects, accessing their properties etc.

If libraries and tools rely on protocols instead of using built-in objects then we would be able to plug any kind of data structure implementing the required protocols into any kind of library that takes advantage of those protocols.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

At least in Chrome, you can add a custom devtools formatter so you can inspect Immutable.js datastructures just like native ones: https://gist.github.com/jsdf/e27e0e467dc8db3fb1e1

> Whereas previously I could simply mouse-over a data structure when I hit a breakpoint (or crash), I now have to do a REPL dance to see what's in any of my data structures.

Why is that? IMHO, this sounds like a problem with the dev tools more than anything.

Because the data contained inside immutablejs structures is opaque. It uses "structural sharing" which probably means internally it's more like a fragmented hard drive than a linear sequence of data.

How do they even improve performance with Redux?

If the whole state is one immutable tree, then the next state is a new tree and the whole app had to be rendered again.

I know it probably doesn't work like that, but this is what I think when I read about immutability.

I imagine it works somewhat like this example:

If the toplevel object contains 3 items:

  { messages: list
    users: list
    me: object }

and the toplevel component contains 3 components that correspond to these 3 sub-states: MessageList, UserList, MyInfo

then updating the user list will only cause a re-render of the toplevel component and UserList, but not MessageList or MyInfo or their child components (the same VDOM will be reused and no diff / patching will be performed on that part of the VDOM / DOM, respectively)

Something like

  if (this.shouldComponentUpdate(...)) {
    return this.render(...)
  } else {
    return this._oldVDOM;
  }

then the diff algorithm can quickly compare by reference equality and only fall back to deeper object equality if the reference equality returns false.

Ah. I thought the diff would re-render all children, if their parent state changed.

Reply on news.ycombinator.com