should objects with custom prototypes really get immutablized? about seamless-immutable

[pbc]

I have just run into this problem when trying to create a list of file uploads which needs to store the original File objects because without them you won't be able to send the files.

[jedwards1211]

In any case this was one of the primary reasons I went back to Immutable.js. I was tempted to fork this project, but didn't have time.

[pbc]

I found another solution. Regular objects + RamdaJS

• http://ramdajs.com/0.17/index.html
• http://ramdajs.com/0.17/docs/

My favourite method is "evolve" because it solves so many problems and it's all immutable

[sudhakar]

Unfortunate that it breaks React's common usage pattern. But for a immutable lib, it makes sense to immute all methods which creates new objects.

However, it would be awesome if there's an api to avoid creating immutables when it is not required..

[jedwards1211]

@sudhakar With over 9000 stars on Immutable.js, which allows mutable objects to be stored inside immutable objects, it's clear plenty of people think the most useful behavior is not to automatically immutablize everything.

"Makes sense" is vague; a more concrete design goal is to make a library convenient for common use cases. I'd argue that mapping to mutable objects is a fairly common use case, as in my above example, and it's one that Immutable.js is a lot more convenient for.

[sudhakar]

@jedwards1211 I dont have a strong opinion on this. I am all up for having mutable methods being part of the API. Changing the map or filter methods to return mutable objects is a big call. @rtfeldman might be the right person to decide on that.

BTW, there's already a thread open to have mutuable api. See more discussion on #56 & chime in with your proposal so that others in community can throw in their thoughts.

Note that I am not a maintainer/owner of this repo. I am just a user like who wants to use it with React ;)

[jedwards1211]

I know you're not the owner :)

What I'm talking about map and filter doing is a bit more subtle. The way they work in Immutable.js is to return an immutable array containing the exact objects returned by your mapper function: if it returns mutable objects, you get an immutable array with mutable objects as elements. Oftentimes when your source object is immutable all the way down, your mapper function will just return the result of some Immutable.js method calls on the elements, which return other immutables, meaning map will return a fully immutable array anyway. But if your mapper function returns something completely different, like React elements as in my example, you'll get an immutable array containing (mutable) React elements.

[jedwards1211]

In any case, you might have noticed that Feldman hasn't commented on these threads at all...I think he's not even interested. I'd be happy if someone made a competing fork

[jedwards1211]

@pbc using Ramda is kind of nifty. What I really want to know is how well Immutable.js performs compared to copying JS objects. Supposedly it can share most of the unchanged data between objects saving time and memory.

[davidspiess]

I stumbled upon the same issue. One way to get around it, would be using lodash instead of the native map function...

_.map(items, (item, i) => <div key={i}>{item}</div>);

...or convert it to a mutable array before performing the map

items.asMutable().map((item, i) => <div key={i}>{item}</div>);

[jedwards1211]

Yes...I'm trying to argue that it shouldn't be necessary to do that

[rtfeldman]

Sorry I took so long to respond to this.

I totally understand the idea here, but to me the invariant that calls to Immutable() consistently result in values that are immutable is more important than this convenience of not having to call .asMutable() or use something like _.map. I think the value of API consistency wins here.

Thanks for raising this point, and for the discussion, but I'm going to close this just to be totally clear on where I stand on this: calls to Immutable() should always return values that are immutable.

[jedwards1211]

Okay, well, I will stick with ImmuableJS then.