Array.prototype.toObjectByProperty( element=> )

Alexander Jones alex at
Thu Aug 10 22:24:06 UTC 2017

As far as I'm concerned, "most data arrays" — at least the ones you're
speaking about — should actually be `Map`s. And their iterators (from, and
to) yield key-value pairs. There is no syntax for a strict pair, so
2-element arrays have to do.

I'd still rather see some approach to generator expressions and/or iterator
functions (like `map`, below) finally enter the standard somehow.

const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age: 43},

// Python generator expression
const myIndexByName = new Map([, _] for _ of allThePeople);

// map function to transform iterables you can argue about the argument
order ;)
const myIndexByName = new Map(map(allThePeople, _ => [, _]));

// equivalent to, but without the intermediate Array
const myIndexByName = new Map( => [, _]));


On 10 August 2017 at 10:53, Naveen Chawla <naveen.chwl at> wrote:

> I've yet to see any demonstration code use case for a `fromEntries` where
> it would ever be preferable over a `fromIterable`, seeing as most back end
> API JSON data arrays, and most data arrays in general for that matter, do
> not come in the form of "entries". I would suggest that a `fromIterable`
> with a `valueFromElement` callback, rather than being a "Swiss Army knife",
> addresses the fundamental building block of an object, namely keys and
> values, covering e.g. the "recentCountries" use case example code a few
> posts back with minimal effort.
> On Thu, 10 Aug 2017 at 14:44 T.J. Crowder <tj.crowder at>
> wrote:
>> On Thu, Aug 10, 2017 at 9:49 AM, Naveen Chawla <naveen.chwl at>
>> wrote:
>> >
>> > I think a property value callback is needed for completeness (not
>> > easy to achieve the same functionality without it.
>> In my view, a Swiss Army knife is not a good API function. (These are
>> always, of course, judgement calls.) The `[key, value]` case can be
>> addressed with Darien's `Object.fromEntries`. I've literally never needed
>> that, but if one does, having something specific for it which fits into the
>> `[key, value]` ecosystem makes sense to me. That's why I've said several
>> times now that my suggestion and Darien's draft proposal are complementary,
>> not conflicting/competing. In fact, it may be useful to combine them (but
>> not the functions they define).
>> Separately, I wonder how a second callback (in the case where it's a
>> callback) compares in terms of performance and memory churn with returning
>> `[key, value]` arrays.
>> > Keying by a string property name should, in my view, be a separate
>> > function
>> I don't see the need. If it does exactly the same thing, just using a
>> string directly rather than calling a function, then like `String#replace`
>> I'm happy for it to handle that. Again, though, these are always judgement
>> calls.
>> -- T.J. Crowder
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list