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

[Jordan Harband]

If you have an object, you can already `Object.assign({}, object)`, or
`Object.defineProperties({}, Object.getOwnPropertyDescriptors(object))`,
with no intermediary, as of ES2015 and ES2017 respectively.

The value here for something new would be
`Object.fromEntries(Object.entries(object).map(…).filter(…))` or similar.

I haven't seen any suggestions for anything different than those three
patterns; am I missing something?

On Mon, Aug 7, 2017 at 10:31 PM, Darien Valentine <valentinium at gmail.com>
wrote:

> > forced into it as an intermediary
>
> Fortunately, no force is involved :)
>
> T.J. Crowder indicated an intention to draft a proposal that I believe
> aligns
> with your ideas for converting objects to a single object by key with an
> all-in-one map+compose method. It is not necessary for there to be only a
> single
> proposal in this space — aside from the fact that having diversity of
> ideas on
> the table is healthy, the two ideas do not seem to be in conflict with each
> other.
>
> > has worse performance
>
> It’s a bit hard to speak about the performance of methods no engine has
> implemented, but you might be overestimating the cost of
> `Array.prototype.map`.
>
> > The [key, value] pattern was originally introduced for Maps to allow
> objects
> > as keys [...]
>
> You described earlier a previous unfamiliarity with the various `entries`
> methods on collections. This might have contributed to an impression that
> entries are a concern of Map specifically. While Map introduced entries, in
> real-world code, I think it’s safe to say confidently that the frequency
> of use
> of `Object.entries` for iteration (as illustrated in Logan Smyth’s earlier
> comment) and transformative operations (as mentioned in Jussi Kalliokoski’s
> comment) dwarfs that of its use for map initialization.
>
> > Yes unfortunately this doesn't apply to forEach, [...]
>
> Are you referring to destructuring? It does:
>
>     const obj = { apples: 2, bananas: 17, blueberries: 9 };
>
>     const numberOfFruitsThatStartWithB = Object
>       .entries(obj)
>       .filter(([ key ]) => key.startsWith('b'))
>       .reduce((acc, [ , value ]) => acc + value, 0);
>
>
> On Tue, Aug 8, 2017 at 12:24 AM, Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
>
>> On Tue, 8 Aug 2017 at 03:28 Logan Smyth <loganfsmyth at gmail.com> wrote:
>>
>>> > Object entries() is another strange case. Iterating over Object.keys
>>> with key=> leaves myObject[key] to access the value, whereas iterating over
>>> Object.entries with entry=> requires entry[0] and entry[1] which seems more
>>> verbose for access, and less readable! So do you know why this was
>>> introduced?
>>>
>>> Keep in mind that the pair syntax plays quite nicely with destructuring,
>>> so assuming the iteration you're describing is something like
>>>
>>> ```
>>> for (const key of Object.keys(myObject)) {
>>>   const value = myObject[key];
>>>
>>>   // do stuff
>>> }
>>> ```
>>>
>>> I at least think it's much more readable to do
>>>
>>> ```
>>> for (const [key, value] of Object.entries(myObject)) {
>>>
>>>   // do stuff
>>> }
>>> ```
>>>
>>>
>> Yes unfortunately this doesn't apply to `forEach`, which I use much more
>> frequently because it allows chaining after `map`, `filter`, `sort`,
>> `concat` etc. and because it's slightly less verbose. I only use `for..of`
>> when I need to break out of a loop, and which frankly I'll stop using
>> once/if `takeWhile`/`skipWhile` are introduced.
>>
>
>
> _______________________________________________
> 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/20170807/65009da7/attachment-0001.html>