[HugoDaniel]

Not really object map. Does not return a new object ;)

[thomasfoster96]

Ah, well this would return a new object:

    Object.entries(obj).map((prop, value) => ...).reduce((newOdj, [prop, value]) => newObj[prop] = value);

I see your point about verbosity :)

[djfm]

Shouldn't it be ".map(([prop, value]) => ...)" ?

I like to write it this way, using as much syntax sugar as possible:

const mapObject = fn => obj => Object.assign( ...Object.entries(obj).map( ([key, value]) => ({ [key]: fn(value) }) ) );

[komali2]

>using as much syntax sugar as possible

It's not possible to say this on the internet without being rude so, apologies, but, why code like that? It genuinely was a struggle to parse (in my brain) your oneliner of code there. If I found this in our code base it would be a huge waste of time and energy.

[djfm]

No offense taken.

I said I like to write it this way, not that I always do it.

> why code like that

It's a fun exercise.

> it would be a huge waste of time and energy

I don't fully agree on this: from the name and signature it's pretty clear what the function does, so you don't need to waste time "parsing" the details. And with unit tests it is also very low-risk.

But that's speculative, in a real project I'd just use lodash.

[rmrfrmrf]

In production code, if I ever have clever one-liners, they're usually offset with just as many additional lines of comments to explain what it's doing and why it works. Plus, this function is generic and would probably be extracted into a utility module, anyway.

To your point, though, this one is pretty esoteric.

[water42]

the trend of style over readability. google recommends avoiding list comprehensions in python yet 99% of stackoverflow python questions have some convoluted list comprehension answer

[tracker1]

I really like that... I've tended to use Object.assign in a reducer, but this works too, and is a little cleaner imho

[thomasfoster96]

Yep, it should be. Thanks for catching it.

[nathancahill]

Your linter will also complain about modifying newObj within the reducer.

[paulddraper]

Which a problem with using linters, not with programming.

[mhluongo]

Spread syntax should cover linter issues

  Object.entries(obj).map(...).reduce((acc, [prop, value]) => ({...acc, prop:value}))

[Rotten194]

isn't that hideously inefficient? you're making a new object each iteration.

[Touche]

But purity.

[djfm]

it's very unlikely this is going to be the bottleneck in your application

[mintplant]

I wouldn't be so quick to write that off as a performance concern. Creating tons of unnecessary objects is JavaScript's equivalent to programming without regard for cache locality at a lower level, due to the way the JITs work.

[Touche]

It's very unlikely you'll get any benefit from doing it the inefficient way either. Does eslint not support "ignore this part" comments?

[tracker1]

In those cases, I usually use

    Object.assign(acc, { [prop]:value })

While not sure if `[prop]` is better or worse than not creating a new interstitial object.

[v413]

why not just use acc[prop] = value ?

[elmigranto]

Assignment does not return `acc`.

[nawitus]

Which linter rule is that?

[mirekrusin]

The one that doesn't like modifying function arguments?

[nawitus]

Usually that only disallows reassignment of function arguments. For example, eslint's no-param-reassign rule by default allows modifying the properties of the function argument. However, the "props" parameter for this rule can disallow even the modification of properties of a function's argument.

[xanderjanz]

Even in es5 you can do Object.keys().reduce().