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

Immutable.js – Immutable Data Collections

facebook.github.io

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Immutable.js – Immutable Data Collections

#61

Post by taeric »

drifkin wrote: post #22
moribound wrote: post #21

Earlier quoted context omitted.

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

That was exactly what I was saying. And apologies for my tone. I did not intend this to be a reason to toss immutable collections. I just don't think "easy dirty checking" is a large bonus for them.

Re: Immutable.js – Immutable Data Collections

#63

Post by brentburgoyne »

etrinh wrote: post #40
brentburgoyne wrote: post #33

Earlier quoted context omitted.

I generated docs for Immutable.js using TypeDoc. It can be found here: http://brentburg.github.io/immutable-docs/api/

I used these docs when I was exploring the Immutable.js API! Very helpful, but Immutable just updated to v3 (your docs are v2), which introduces some breaking changes (for example, Vector is now called List). Would you mind updating your docs?

I just updated it to v3.0.2.

Re: Immutable.js – Immutable Data Collections

#64

Post by amelius »

swannodette wrote: post #52

It's great to see more implementations of persistent data structures. I think over time people will begin to see that they allow us to radically rethink how we organize very complex programs that we have long believed are better constructed on stateful objects - user interfaces. It's been thrilling to see people discard many long held assumptions - the ClojureScript community has been running with UIs constructed on…

Cool video. But I don't get it really :S I just skimmed through the documentation and it says:

> In return for this effort, we get powerful debugging tools

Is this the primary purpose of this tool? Or is it the undo feature?

Re: Immutable.js – Immutable Data Collections

#65

Post by ninjakeyboard »

pimlottc wrote: post #43
ninjakeyboard wrote: post #14

Earlier quoted context omitted.

Not sure if I agree - it's more natural to have only immutable collections if taking a functional approach. Eg see scala or haskell. Does strong typing change that? It's very clear if you're whole code base has no side effects what is happening when and where.

> It's very clear if you're whole code base has no side effects what is happening when and where. And how likely is that? It's great if you start with a purely functional project but in most projects you're starting with a existing codebase, and you don't always have the time to go back and change everything when you figure out a better way to do it. So I don't think it would be that unusual for someone to want to us…

I suppose ruby is the example where you have map! and map. I don't know - the java stream API is clear enough IMO. The Java8 approach was to allow mutating functions on collections and then have lazy-non mutative stream api. As a java8 dev, I don't think it's so hard to understand that map on a play promise is non mutative though - I'm not dropping requests for typesafe to change the api.

Re: Immutable.js – Immutable Data Collections

#66

Post by jonahx »

pimlottc wrote: post #44
leebyron wrote: post #24

Earlier quoted context omitted.

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

But it's not the same API. There is a clear and plain specification on what each of those operations do, and the methods on these objects do not do them. I get what you're thinking about re-using what the programmer already knows but this only poisons the well by adding confusion to their existing knowledge. "Push adds a value to a list, oh wait, except it depends what type of list". It is much easier to remember tha…

I think there are two opposing forces: the first, as you say, pushes us away from re-using the same names, because that can cause confusion; the second, however, pushes us to re-use existing knowledge through metaphor.

This second force is ubiquitous in natural language, but common also in programming language where operators like "+" and "[]" are re-used in different contexts without practical ambiguity, and with the benefit of transfer of knowledge through metaphor.

So I think your conclusion -- "New objects with new behaviors should use new language" -- is a bit too strong. On the other hand, in this particular case, the context is very close (array behavior) and the only difference is the immutablity, so confusion is a valid practical concern.

Re: Immutable.js – Immutable Data Collections

#67

Post by jonahx »

zbyte64 wrote: post #19

I have started using this with our React.js project and have been able to squeeze out efficient DOM updates comparable to Om. For fun I also made a library that overloads Immutable.js and JSON operations (and can do the same for mori): https://github.com/zbyte64/dunderdash

Doesn't React already do efficient DOM updates for you with their virtual DOM and it's diffing mechanism? Or are you referring to something else?

Re: Immutable.js – Immutable Data Collections

#68

Post by nawitus »

matchu wrote: post #7
nawitus wrote: post #3

Was this really hosted on Facebook initially? I remember this library before May, which is the date of the initial commit.

This was always Facebook's library, but it didn't always have a pretty homepage. You might be thinking of mori? https://github.com/swannodette/mori

Ah, I was thinking about "immutable.ts":

https://github.com/srenault/immutable.ts

Re: Immutable.js – Immutable Data Collections

#69

Post by skrebbel »

leebyron wrote: post #30
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 mo…

Hi! Just to be absolutely clear, I think that it's completely TypeScript's fault that Immutable.js's TypeScript support is half-assed - you could rather say that TypeScript's support for immutable well-typed data structures is half-assed. My only complaint about your work in that entire story is that the site somewhat implies that it works great in TypeScript, whereas my personal experience is kind of that it doesn't. I have spent weeks trying to use it well with TypeScript, and then dropped it and going for vanilla JavaScript instead. I haven't looked back :-)

I'll see if I can dig up any of the stuff I did to make it work better with TypeScript, but I don't think I could find many substantial improvements to the .d.ts only. What I ended up making was wrappers for some stuff that had more cumbersome syntax, but as a result did allow for more type checking.

About the records, I believe that I might have a couple of ideas. I'll start an issue on github to discuss it.

Post reply on HN