Hi Darien!
The concept of using a 2-element array to represent a key and value is
unique to Maps and if I'm not mistaken, exists purely because there wasn't
a tight, compact alternative that could house a key and value where the key
could be an object.
However, if we are going straight from iterable to Object, I don't think we
should be propagating the "[key, value] as an array" pattern. It's unclean
partly because it's 2 elements max and IDEs can't inherently show warnings
if you accidentally added more, unless it has some intelligence about the
method itself. Partly also because the arrays are not immediately readable
unless you already know the that the arrays mean [key, value].
I'm not convinced that Maps have any real value at all right now vs objects
(despite what the documentation says): currently they only offer the
ability to have objects as keys but without custom key equality (only ===),
and you lose the elegant square bracket syntax for accessing elements,
among other things, so it's unclear to me how compelling the use of Maps vs
objects is at all in real world scenarios, so I'm not sure anything about
Maps should be a pattern for other language features.
Iterables are very generic, since they can include generators, sets etc.
Objects are a fundamental construct, so it makes sense to be able to
cleanly transition between these structures.
Adding the idea to iterable in general (instead of just Array) would look
like e.g.:
```
const cache = iterable.toObjectByProperty(item=>item.id)
```
On Sun, 6 Aug 2017 at 02:12 Darien Valentine <valentin...@gmail.com> wrote:
> FWIW, while I find needs like this common, too, where Map is sensible
> instead of
> Object, it does come out pretty clean:
>
> ```
> const a = [
> {id: "tjc", name: "T.J. Crowder"},
> {id: "nc", name: "Naveen Chawla"},
> {id: "lh", name: "Lachlan Hunt"}
> ];
>
> const index = new Map(a.map(member => [ member.name, member ]));
> ```
>
> Although I’m also puzzled by the suggestion that reducing to an object is
> an abuse,
> I do find I wish there were a complement to `Object.entries`:
>
> ```
> // Object to pairs, and therefore map, is simple:
>
> const map = new Map(Object.entries(obj));
>
> // Converting back is also simple ... but not exactly expressive:
>
> [ ...map ].reduce((acc, [ key, val ]) => Object.assign(acc, { [key]: val
> }));
> ```
>
> Something like `Object.fromEntries` would not provide as much sugar for the
> OP case as `toObjectByProperty`, but it gets pretty close and has the
> advantage
> of being more generic; `toObjectByProperty` strikes me as rather specific
> for a
> built-in, especially since one might want to map by a derived value rather
> than
> a property. Both map<->object and array<->object cases would become more
> expressive — plus it follows pretty naturally from the existence of
> `Object.entries` that there might be a reverse op.
>
> ```
> Object.fromEntries(a.map(a.map(member => [ member.name, member ])));
> ```
>
> In other words, `Object.fromEntries(Object.entries(obj))` would be
> equivalent in
> effect to `Object.assign({}, obj)`.
>
> Would that adequately address this case you think? My sense is that it’s
> better to supply generic helpers before more specific helpers when it comes
> to built-ins.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
