What is the recommended way to deal with no-param-reassign in reducers?

This problem has been discussed before, but I haven’t seen a general agreement on the best way to solve it.

Although this reduce() operation (as a whole) is pure, the callback within it is not, so it breaks no-param-reassign:

const arr = [['fred', 24], ['bob', 32]];

const obj = arr.reduce((accumulator, item) => {
  accumulator[item[0]] = item[1]; // ERROR! no-param-reassign
  return accumulator;
}, {});

// obj === { fred: 24, bob: 32 }

Option 1 – suppress the linter:

const obj = arr.reduce((accumulator, item) => {
  accumulator[item[0]] = item[1]; // eslint-disable-line no-param-reassign
  return accumulator;
}, {});

Option 2 – make a new object each time:

const obj = arr.reduce((accumulator, item) => (
  { ...accumulator, [item[0]]: item[1] }
), {});

Neither option feels great.

1. Suppressing the linter should be restricted to unusual edge cases imo, not everyday idiomatic JavaScript like .reduce().
2. Creating a new object on every iteration creates extra garbage. A programmer can take one look at the operation and see that it’s pure. I realise that technically it’s possible that arr.reduce might refer to something other than Array.prototype.reduce, so the linter can’t make a special exception here. But it feels wrong to write slower code just because of a limitation in the linter.

What’s the best thing to do?

[ljharb]

“creates extra garbage” is a memory concern, and in a memory-managed language, that should be none of the programmer’s. Create a new object on every iteration, which makes the reducer pure (as well as the overall reduce, which is pure in both cases).

However, ignorePropertyModificationsFor is already enabled in the next release of eslint-config-airbnb-base, so if your accumulator is named one of the things it’s enabled for, it will be allowed.

[ljharb]

You’re not describing something a JS developer should be thinking about. GC is negligible most of the time - you don’t need to “code really precisely” (something most competent developers do on the web), you just need to write clean code.

If you close a tab and your RAM doesn’t go down, then clearly that’s a bug in the browser - no amount of attempted memory management in JS can fix that.

You clearly prefer to write your JS code as if it was C, tightly controlling memory usage. Go for it! This guide does not endorse or encourage that mindset, nor will it.