sebmarkbage / ecmascript-immutable-data-structures Goto Github PK

First, I would like to confirm some assumptions about Records. I think they should be added to the .md file for more clarity.

• records will work with subscripts the same way as objects do

const a = #{a: 1}
a.a === 1
a['a'] === 1

• Object.assign will work for records as well.

const b = Object.assign(#{}, {a: 1}, {b: 2}, #{b: 3})
b === #{a: 1, b: 3}

• Values in a record can still be functions and other non-value types.
• The only way to convert a record to an Object would be to use Object.assign

Some questions:

• Is there no way of adding or updating a key on a record? With objects you can just set a new value. That seems impossible with records, but potentially very useful.
• Will other class methods on Object also work on records? Object.keys for example?
• Object is javascript are currently ordered in all major implementations. Will records also be ordered maps in this way?
• What is the value of keeping separate types for record and ImmutableMap? Perhaps it's a better idea to combine the two into a single type. It would be called ImmutableMap, but it would actually be an orderedMap, just like javascript Object is practice.

It seems like the following or something like it should be possible:

const rec = Record({ a: 1, b: 2 });
typeof rec === 'record';
rec.a === 1;
rec.b === 2;

And to clarify inheritance:

function Box() {}
Box.prototype.a = 1;
const box = new Box();
box.b = 2;

const rec = Record(box);
typeof rec === 'record';
('a' in rec) === false;
rec.a === undefined;
rec.b === 2;

When you need to add multiple values, there is little sense in doing separate operations (and also creating intermediate objects) like:

const a = ImmutableMap([['x', 1], ['y', 2]]);
const b = a.set('z', 3).set('t', 4);

It would be nice to have .extend method that would allow to do things like:

const a = ImmutableMap([['x', 1], ['y', 2]]);
const b = a.extend({z: 3, t: 4}); // or a.extend(#{z: 3, t: 4});

From what I can tell all the proposed types have extension operations defined but non of them have a subtraction, maybe syntax could be borrowed from elm ?

const point3d = {x: 1, y: 2, z: 17}
const point2d = {...point3d - z}

There already seems to be a toJSON method on the prototypes of the immutable types.

There should be a new method of JSON as well.

JSON.parseImmutable

This would return an immutable values instead of a mutable one.

In case the toImmutable method is added to the prototypes, this would as simple as this, behind the scenes:

JSON.parseImmutable = (string) => JSON.parse(string).toImmutable()

The actual implementation will be smarter in that it will not throw an error if the JSON value is already immutable (string/number/bool).

I don't see anywhere in docs but I'd like to treat my immutable data structures like normal JS ones, in that I dislike having to use get and set rather than just =. I assumed this spec would have something along those lines but I didn't see it explicitly.

As per the title, what is the current progress for the Stage 0 Proposals for the immutable-data-structures? I know many people have been waiting to see how this "feature" progresses.

One of the most common problems I run into while using 'immutable-js' is forgetting to use the .get method and instead trying to read values from a Map/Vector using a subscript.

So I end up trying to read a value from a Vector like so:

v[0]

It would be great if it was possible to create some way of using the sugar syntax with immutable values today. It's easy to use sweet-js to create sugar initialisers. Such that #[1, 2] can become Immutable.Vector(1, 2). But it is much more complex task to walk through the entire codebase, detect the value types and convert places where subscripts are being used to .get.

Perhaps a new feature for Babeljs? @sebmck thoughts?

It's often nice to have literals for immutable sets, both for writing and for printing. This is obviously far less important than any of the semantics that you've laid out, but what about #<1 2 3> for ImmutableSet literals? I'm of course partial to Clojure's #{1 2 3} syntax, but that's taken in this proposal already.

How would this be achieved?

Would love to get some examples for:
ImmutableVector.prototype.copyWithin (target, start [ , end ] )

And

ImmutableVector.prototype.fill (value [ , start [ , end ] ] )

Can you explain: how new record:

const xy = #{ x: 1, y: 2 }; // frozen value type
const xyz = #{ ...xy, z: 3 }; // functional extension

is different from:

const xy = Object.freeze({ x: 1, y: 2 });
const xyz = Object.freeze({ ...xy, z: 3 });

?

And how new tuple:

const xy = #[ x, y ]; // frozen value type
const xyz = #[ ...xy, z ]; // functional extension

is different from this:

const xy = Object.freeze([ x, y ]); // frozen value type
const xyz = Object.freeze([ ...xy, z ]); // functional extension

?

If they're not deep immutable, it's looks like there are no differences. I suspect new types have some performance gains, but don't understand how it can be achieved.

There are lots of methods already defined on the prototypes of the types.

I propose two more methods. The idea is to have the same capability as 'fromJS' and 'toJS' as seen on 'immutable-js'
On all the immutable types:

.toMutable

This would return a new mutable object/array/Map/Set with the same data as the Immutable value. It will not mutate the Immutable Type.

On the other hand, the Object.prototype, Array.prototype, Map.prototype and Set.prototype, should get one extra method:

.toImmutable

This would return a new Immutable type with the same values as the ones in the mutable types.

• In case of Objects, only the keys that are on the object themselves (and not prototypes) will be copied over.
• In case of arrays, and 'holes' will be converted to undefined
• There doesn't seem to be any edge cases with Maps of Sets.

These methods will also be recursive, as in all sub values, will be made mutable/immutable as well.

Polyfills for these methods are fairly trivial, and I'll be posting them here in more comments soon.

I don't see any note in the document whether those immutable data structures can contain mutable items in them or not. I would personally advocate against allowing that since:

1. That would make a lot of otherwise possible optimization impossible.
2. If it's immutable all the way there is a possibility of cheap transfer of them over workers (or why not even sharing).

The combined type would work the same way as OrderedMap in Immutable-js

Since Records are about Data, it doesn't make sense to keep them limited to strings for keys.

Would like to know if there is a performance story to be made about Records.