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.crow...@farsightsoftware.com>
> On Thu, Aug 10, 2017 at 9:49 AM, Naveen Chawla <naveen.c...@gmail.com>
> > 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
> -- T.J. Crowder
es-discuss mailing list