Array.prototype.toObjectByProperty( element=>element.property )

Jordan Harband ljharb at gmail.com
Sun Aug 6 19:32:12 UTC 2017


If anything *were* to be added, it would surely be a static method that
took an iterable of entries and returned an object, and it would surely
have the semantic that `new Set(Object.entries(thisThing(entries)))` and
`new Set(entries)` were two conceptually equal sets (iow, that each
corresponding entry's key were ===, modulo ToPropertyKey conversion, and
each corresponding entry's value were ===).

I'm not necessarily proposing this at all or any time soon, but one thing
that *would* help me or a future champion (if proposed) is if interested
parties wrote up a convincing proposal readme - rationale, similar patterns
in the ecosystem, motivating use cases, etc.

On Sun, Aug 6, 2017 at 11:31 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> I have a better idea: how about `Object.from(iter)`, where `iter` is
> an iterable of `[key, value]` pairs?
>
> ```
> const a = [
>   {id: "tjc", name: "T.J. Crowder"},
>   {id: "nc", name: "Naveen Chawla"},
>   {id: "lh", name: "Lachlan Hunt"}
> ];
>
> const object = Object.from(a.map(o => [o.id, o.name]))
> ```
>
> We already have `Object.entries(object)`, returning an array of `[key,
> value]` pairs, so this would effectively be the inverse of that -
> `Object.from(Object.entries(object))` would be equivalent to
> `Object.assign({}, object)` assuming native prototypes are unmodified.
>
> (Yes, it's like `_.zipObject(pairs)` from Lodash)
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Sat, Aug 5, 2017 at 4:42 PM, Darien Valentine <valentinium at 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 at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170806/ecdb7393/attachment.html>


More information about the es-discuss mailing list