.map() equivalent for objects - Object.mapEntries()

💡 Ideas
1

I'm proposing we add the method Object.mapEntries() into the language, to allow one to map one object to another object. This is a very common task, and it would make a lot of code just a little more readable if there was a canonical way to do so.

It could be defined as follows:

Object.mapEntries = (obj, mapFn) => {
  const entries = Object.entries(obj)
  return Object.fromEntries(entries.map(mapFn))
}

Example usage:

const users = {
  NKpiZ: { name: 'Sarah', age: 5 },
  UaAFu: { name: 'Samuel', age: 10 },
  avTRz: { name: 'Samantha', age: 15 },
}

const userIdToAge = Object.mapEntries(users, ([id, { age }]) => [id, age])
// userIdToAge is { NKpiZ: 5, UaAFu: 10, avTRz: 15 }
const nameToAge = Object.mapEntries(users, ([, { name, age }]) => [name, age])
// nameToAge is { Sarah: 5, Samuel: 10, Samantha: 15 }
const nameToId = Object.mapEntries(users, ([id, { name, age }]) => [name, id])
// nameToId is { Sarah: 'NKpiZ', Samuel: 'UaAFu', Samantha: 'avTRz' }

We could potentially add Object.mapKeys() and Object.mapValues() too, but mapEntries() alone would be a big win.

1 Like
2

Would be nice alternative to the ‘reduce pattern’ I’ve seen a bit.

toEntries(obj).reduce((out, ([key, value]) => {
  out[key] = change(value);
  return out;
}, {})

FromEntries is also another case where I’ve wanted the pipeline operator:

toEntries(obj)
  .filter(([key]) => condition(key))
  .map(([key, value]) => [key, change(value)])
  .filter(([_, value]) => condition(value))
  |> fromEntries;
3

See the comments at agoric-sdk/objArrayConversion.js at 4890dcdbee725d15c1656f3882c6d49aa030778e · Agoric/agoric-sdk · GitHub

The comments are on essentially the same code. Once I started explaining it well enough for it to be used reliably, I was surprised at how much I needed to say.

I purposely chose to do entries.map(entry => mapFn(entry)) rather than entries.map(mapFn) because in the latter, the binding of other parameters of mapFn beyond the first doesn't make any sense as part of the meaning of mapEntries.

I support this abstraction. In writing that explanation, I came to appreciate all the possible variations and ways to get this wrong. So standardizing on this one would be good.

1 Like
4

Good point @markm, some of those other parameters wouldn't be needed by the mapping function. Certainly, an index shouldn't be provided (yes, object ordering is stable, but we probably shouldn't encourage code to depend on the order of the object's entries). However, it might be good to pass in the original object as a second parameter? Same way array.map() passes in the original array as the third parameter? I've personally had never found that to be a useful parameter, but I assume others have.

Object.mapEntries = (obj, mapFn) => {
  const entries = Object.entries(obj)
  return Object.fromEntries(entries.map(entry => mapFn(entry, obj)))
}
5

Since we don't have a good analogy for the second parameter and would therefore omit it, we no longer have a least-surprise reason for the original-object parameter. Other than least-surprise by symmetry, I do not find any other reason for this extra parameter compelling. We should omit it.

6

Sounds good to me - unless someone can think of a compelling use case for the original object reference parameter, it makes sense to just leave it out.

7

Feedback seems to be generally positive, so I went ahead and threw together a proposal repo here to help aid further discussion.

As I was researching how other languages and libraries handled this issue, I found that most of them did so by only providing a mapValues() function, or both mapValues() and mapKeys(). None of the languages/libraries I looked at allowed modifying both the key and value at the same time.

I still think Object.mapEntries() would be an intuitive and powerful tool in the javascript ecosystem, especially since we already have a notion of what an "entry" means, because of functions such as Object.entries() or Object.fromEntries(). But, there's certainly room for discussion here on whether we want to pursue the original idea of having Object.mapEntries(), or if we should have an implementation similar to other languages/libraries and have both Object.mapKeys() and Object.mapValues(), or do some combination of both. (I also outlines these thoughts in the github repo, under the "Comparison" heading).

8

Another alternative could be just “map” to avoid asks for keys/values - or, map with an optional second argument that defaults to “entries” but can also be “keys” or “values”.

9

When you say

map with an optional second argument that defaults to “entries” but can also be “keys” or “values”.

Are you referring to using a literal string as a second argument to control the behavior of the mapping function? i.e. Object.map(obj, entries => newEntries) and Object.map(obj, 'keys', key => newKey). I don't think any ECMAScript API uses string sentinels like that.

If we do choose to just have a single Object.mapValues() function, I think it would make sense to just give it your suggested name of Object.map() instead.

10

This has been proposed before and was rejected by the commitee. Please see GitHub - tc39/proposal-object-iteration: ECMA TC39 proposal for making mapping over Objects more concise and its issues for existing discussion.

11

Ah right, third argument then :-)

12

Ah man, I guess this is a lost cause then :(

I don't think they'll ever get people to start using the Map() in place of normal objects all the time - there's so much syntax support around normal objects that won't ever exist with Map(). (not that Map() isn't useless, it's plenty useful, it's just more verbose to use).

I do see the concern about it being a slippery slope (assuming they're talking about a slippery slope of adding other functions such as Object.filter()) - I was a little worried about the same thing.

13

I don't see how Object.mapEntries(obj, fn) is any better than Object.fromEntries(Object.entries(obj).map(fn)) except for a mild perf boost.

I do see the value in Object.mapValues(obj, fn), though - engines could make it as fast as Array.prototype.map if not faster as they can just reuse the existing object's type info.

14

@theScottyJam @bergus That proposal rejection ends with "More investigation to follow."

I have seen this pattern Object.fromEntries(Object.entries(obj).map(fn)) scattered across almost every repo I've touched, easily thousands of times. Maps are helpful, but there is no escaping the use of plain objects, especially as they are JSON-safe (tons of value-add already right there).

A simple Object.mapEntries(obj, fn)

Benefits:

  • some perf boost, as @claudiameadows mentioned
  • much easier to type
  • easier to understand at a glance

This is not so dissimilar to when TC39 opted to add Array.prototype.at(N). We could already achieve identical functionality via .slice(N)[0], which is hardly more complex, and yet this small quality-of-life improvement has made index-based references for arrays drastically simpler.

Here is just one simple example, and even here, I can easily feel the weight of the change, more in practice than in observation:

// before
Object.fromEntries(
  Object.entries(changes).map(([key, { current }]) => {
    return [key, current];
  })
)

// after
Object.mapEntries(changes, ([key, { current }]) => {
  return [key, current];
})

Possibly the biggest selling point of all— I'm confident, however unfoundedly, that at least 50% of the times developers use fromEntries, they use it to support this exact pattern.

fromEntries and entries are crucial as they are the foundational modular pieces that make this pattern achievable without greater abstraction. However, in terms of usage, mapEntries might actually be more widely used than either of these other two combined.

15

You would also need/want flatMapEntries I would think in case the desired transform isn't 1:1