Possibility of creating an immutable-js based polyfill?

[nmn]

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?

[cameronbourke]

@nmn I know your comment was over a year ago, but what are your current thoughts on this? I think it would be great if we had a Babel plugin to transform the syntax into Immutable.js method calls.

[nmn]

There are some issues with the idea.

1. #[] and #{} syntaxes are not supported in Babylon.
2. Alternatively there's a possibly where we could just convert all arrays and objects literals to immutable.js versions. This comes at the very high cognitive cost that any native API that gives you a raw JS array or object will surprise and confuse you. And also when passing anything to a native API or external library you'll have to manually call .toJS() even if you use a literal. [1, 2, 3].toJS()
3. The only that kind of makes sense to me is based on some sort of convention based on the variable name, and that's a terrible idea.

---

However, with Proxies in modern JS VMs it's possible to make the Immutable.Map[keyName] work without any trickery with a thin wrapper around Immutable.JS. Of course, Proxies are slow and you should not rely on them in production, but with a few warnings and compiler config, you make it so that you get good warnings whenever you accidentally use [0] on an immutable value while everything still working. This way, in development, silly mistakes won't cause crashes, but will still warn you that you're doing something wrong.

[cameronbourke]

@nmn In regards to your points.

1. #[] and #{} syntaxes are not supported in Babylon

I'm not very familiar with Babylon, but could we write a plugin that supports the syntax? I like the idea of using Babel to be able experiment with a new syntax and so it would be cool, if it's not already, to let Babylon be extended. Another way to support the syntax, might be to use macros with sweetjs.

---

Using Proxies

You are right, I didn't realise how slow Proxies are! However, I think this would be great, if at the very least. One of the problems with Proxies is we could only support getters, as setters (for example map2 = (map1.key = value)), currently cannot return a value.

Is there value in having this functionality as standalone lib for Immutable.js? This seems like it would be a perfect fit within the core! Although, now that I say that, I understand trying to land this in the core repo initially would be pretty time consuming, so maybe it's better to create it as an auxiliary lib and have it merged in down the track if there is a good case for it.