4 ms·

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 cra

by davedx 11y ago

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.

gcanti 11y ago
Hi, shameless plug: another (typed) immutable data structure library, https://github.com/gcanti/tcomb 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 https://github.com/gcanti/redux-tcomb (Immutable and type-checked state and actions for Redux)
- jlongster 11y ago
  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.
jdc 11y ago
> 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.
- davedx 11y ago
  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.
k__ 11y ago
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.
- spion 11y ago
  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.
  - k__ 11y ago
    Ah. I thought the diff would re-render all children, if their parent state changed.
spion 11y ago
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/Reference/Iteration_protocols https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
mambodog 11y ago
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 https://gist.github.com/jsdf/e27e0e467dc8db3fb1e1

by davedx 11y ago

gcanti 11y ago

Hi, shameless plug: another (typed) immutable data structure library, https://github.com/gcanti/tcomb 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 https://github.com/gcanti/redux-tcomb (Immutable and type-checked state and actions for Redux)

jlongster 11y ago
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.

jdc 11y ago

> 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.

davedx 11y ago
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.

k__ 11y ago

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.

spion 11y ago
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.
- k__ 11y ago
  Ah. I thought the diff would re-render all children, if their parent state changed.

spion 11y ago

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/Reference/Iteration_protocols https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

mambodog 11y ago

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 https://gist.github.com/jsdf/e27e0e467dc8db3fb1e1