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

[Naveen Chawla]

Another benefit of iterable toObjectByProperty(element=>element.id) is that
it can be placed at the end of a transformation chain of `map` `sort`
`filter` `concat` etc.:
```
const
    cache =
        sourceIterable
            .filter(item=>item.isValid)
            .toObjectByProperty(item=>item.id)
```
It'd be great to know if anyone from TC39 is going to propose these ideas
(could I submit a README.md in order to help? If so where?)


On Tue, 8 Aug 2017 at 11:18 Jordan Harband <ljharb at gmail.com> wrote:

> 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
>>
>>
> _______________________________________________
> 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/20170808/99a09fc7/attachment-0001.html>