Immutable.js – Immutable Data Collections • Hacker News Board

Re: Immutable.js – Immutable Data Collections

#21

Post by moribound » Sat, Nov 01, 2014, 2:23 AM UTC

taeric wrote: post #13

baddox wrote: post #6

Earlier quoted context omitted.

One benefit is that you can do simple O(1) equality comparisons in UI libraries like React to determine whether data has changed (and thus whether UI needs to be refreshed).

This doesn't necessarily work. Consider scenarios where you do one edit and then effectively undo it before the redraw. Or, more realistically, two rapidly successive edits effectively undo each other. Also, one could just as easily keep a dirty bit oneself.

I don't follow. What's wrong with effectively undoing an edit before a redraw? Why do I care about the intermediate state?

Re: Immutable.js – Immutable Data Collections

#22

Post by drifkin » Sat, Nov 01, 2014, 2:38 AM UTC

moribound wrote: post #21

taeric wrote: post #13

Earlier quoted context omitted.

This doesn't necessarily work. Consider scenarios where you do one edit and then effectively undo it before the redraw. Or, more realistically, two rapidly successive edits effectively undo each other. Also, one could just as easily keep a dirty bit oneself.

I don't follow. What's wrong with effectively undoing an edit before a redraw? Why do I care about the intermediate state?

I think taeric is saying you "effectively undo" an edit, meaning that you could modify the state to a new state that happens to be the same as the old state (so it'll be a different object).

Re: Immutable.js – Immutable Data Collections

#23

Post by mcav » Sat, Nov 01, 2014, 3:01 AM UTC

ScottBurson wrote: post #4

> The difference for the immutable collections is that methods which would mutate the collection, like 'push', 'set', 'unshift' or 'splice' instead return a new immutable collection. I think this is an unfortunate design decision which should be reconsidered. Functional operations should have different names than side-effecting operations. In general, I think that while side-effecting operations are commonly verbs, f…

That's silly. All of the methods are side-effect-free. It'd be useless and confusing to suffix some methods and not others.

Re: Immutable.js – Immutable Data Collections

#24

Post by leebyron » Sat, Nov 01, 2014, 3:01 AM UTC

ScottBurson wrote: post #4

> The difference for the immutable collections is that methods which would mutate the collection, like 'push', 'set', 'unshift' or 'splice' instead return a new immutable collection. I think this is an unfortunate design decision which should be reconsidered. Functional operations should have different names than side-effecting operations. In general, I think that while side-effecting operations are commonly verbs, f…

This is great feedback and a decision that I didn't take lightly.

I ultimately decided that the mental cost of remembering a new API would outweigh the potential for accidental return value mis-management.

It's hard to make a decision like this sans-data, so I had to make a gut call. I'm really interested to hear feedback of issues encountered in-practice due to this. Of course, if I'm wrong about this (and there's always a reasonable chance I am!) then I would seriously consider changing the method names in a future major version.

Re: Immutable.js – Immutable Data Collections

#25

Post by leebyron » Sat, Nov 01, 2014, 3:07 AM UTC

ebabchick wrote: post #8

Random observation -- what's up with almost 20 of the 24 'contributors' to this project mostly having made 1 edit changes to the README? Is this some kind of pervasive Github resume padding scheme that I'm just now picking up on? (it will show the repo in the "Repositories contributed to" section of your profile even for just those 1-line README edits) https://github.com/facebook/immutable-js/graphs/contributors

Not nefarious, but definitely something to keep in mind if you recruit via github committer lists :)

I accept any reasonable pull request, even if it's a spelling fix. There have been some great bug fix pulls as well.

Re: Immutable.js – Immutable Data Collections

#26

Post by leebyron » Sat, Nov 01, 2014, 3:10 AM UTC

Havvy wrote: post #12

So, how does this compare to Clojurescript's Mori?

Performance: comparable Data-structure techniques: nearly the same API: do you like point-free functions (mori) or methods (immutable.js)

mori is a direct compile of clojurescript's excellent data structures and functional tools (written in clojurescript, of course) to javascript. It favors a clojure-style API.

immutable.js is entirely written in JavaScript and favors Idiomatic JS style API.

Re: Immutable.js – Immutable Data Collections

#27

Post by franciscop » Sat, Nov 01, 2014, 3:14 AM UTC

I think I'm getting the example wrong. Wouldn't this:

    var map = Immutable.Map({a:1, b:2, c:3});
    map = map.set('b', 20);
    map.get('b'); // 20

Give 2 instead of 20, since b is inmutable?

Re: Immutable.js – Immutable Data Collections

#28

Post by rtfeldman » Sat, Nov 01, 2014, 3:17 AM UTC

franciscop wrote: post #27

I think I'm getting the example wrong. Wouldn't this: var map = Immutable.Map({a:1, b:2, c:3}); map = map.set('b', 20); map.get('b'); // 20 Give 2 instead of 20, since b is inmutable?

Only the map variable points to an immutable object. The second line reassigns that variable to a new (also immutable) Map instance, which is an exact copy of the original except that b has been changed.

Does that make sense?

Re: Immutable.js – Immutable Data Collections

#29

Post by leebyron » Sat, Nov 01, 2014, 3:19 AM UTC

taeric wrote: post #13

baddox wrote: post #6

Earlier quoted context omitted.

One benefit is that you can do simple O(1) equality comparisons in UI libraries like React to determine whether data has changed (and thus whether UI needs to be refreshed).

This doesn't necessarily work. Consider scenarios where you do one edit and then effectively undo it before the redraw. Or, more realistically, two rapidly successive edits effectively undo each other. Also, one could just as easily keep a dirty bit oneself.

Of course there's no way to know in O(1) time if you've done two edits that just so happen to sum to no-op, regardless of if you're using Immutable.js or not.

However, depending on how to implement undo, you might be in good shape with Immutable.js. For example: you might keep a stack of the last few changed data around, and an undo could just pop off the stack in which case you can know if your oldData === newData in O(1).

---

Keeping dirty bits around to determine when you need to operate on your data again is totally viable, there's nothing wrong with that approach, especially for smaller applications. Some frameworks designed for large applications even employ this technique.

For larger applications, in my experience, the dirty bits tend to add up and create a lot of state management overhead, and soon you find a majority of your code cautiously stepping around mutable state instead of just making your application do what it's supposed to do.

The primary thesis of Immutable.js (and persistent data structures in general) is to illuminate the option of having data which promises to never change and thus making memoization trivial. If you have an application which can take advantage of memoization for real performance improvements, then using these kinds of structures can be a big win.

Re: Immutable.js – Immutable Data Collections

#30

Post by leebyron » Sat, Nov 01, 2014, 3:26 AM UTC

skrebbel wrote: post #18

I've been using this (v2, though) rather extensively the last few months so I figured I'd share some experiences. First off, it works great. The TypeScript definition file also works fine as an API documentation of sorts, although it would be nice if some web site with a clickable TOC could be generated from it. I was a little confused at the beginning how the "Sequence" base class (changed name to Iterable in v3) wa…

I'm not happy with the Records impl yet. This is great feedback and resonates with some things I've already been thinking about. I'm especially not happy about how Records play with Typescript at the moment.

Also, please keep feedback coming about Typescript. I'm sorry you feel it's half-assed, I'm trying to make the best of what Typescript gives me. You might notice that the .d.ts file is full of comments where a more expressive type system would allow more accurate type information.

If you have concrete suggestions for improving the TypeScript definition file, please please hop over to github.com/facebook/immutable-js/issues and write them up.