[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?

[Prefinem]

Yes it does

// eslint-disable-line your-rule-to-ignore

[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.