Thoughts on "Never mutate parameters"

[AlicanC]

1- This rule's "Do not reassign parameters" part should be split into another rule, because reassigning a parameter isn't actually mutation.

Plus it sounds like no-param-reassign rule also covers mutation, but it doesn't. It would be nice to easily see what gets covered by ESLint and what doesn't.

---

2- Why shouldn't we reassign parameters?

Overwriting parameters can lead to unexpected behavior, especially when accessing the arguments object.

Accessing arguments is already discouraged. Should we really care about breaking something we aren't supposed to use? What are other unexpected behaviors can this cause?

[sandyjoshi]

2- In javascript objects are passed by reference, so when you pass object to any function and modify that object inside that function, it means the reference of object which is passed into a function will get affected. I think it is main "unexpected behaviors".

[AlicanC]

Reassigning parameters doesn't do that. Mutating parameters do that.

const myObj = {
  adele: 'hello',
};

function myFunc(myParam) {
  myParam = {};

  myParam.adele = 'rolling in the deep';
}

myFunc(myObj);

console.log(myObj); // { adele: 'hello' }

Mutating parameters is wrong, I have no objection to that rule.

[ljharb]

Reassigning parameters deoptimizes in many engines, specifically v8 - it's a horrible idea to do it. Variables are free, and creating new ones rather than reusing old ones makes code much clearer.

(In addition, nothing in JS is passed by reference, everything is passed by value, where objects are a form of "reference value" - this is a good read on the subject)

A PR would be welcome if there's verbage that could be cleared up.

[carpeliam]

Not sure if this is the place for additional thoughts, but I'm a little unsure as to how I should handle something like array.forEach((obj) => { obj.prop = true; });. Other than that, I'm a fan.

[ljharb]

@carpeliam by copying instead of mutating: array.map(obj => Object.assign({}, obj, { prop: true }))

[noelleleigh]

@ljharb I'm not sure that solution works in the case of setting the style attributes of a list of DOM nodes:

nodeArray.forEach(node => (node.style.display = 'none'));

What do you do when you have to mutate parameters in-place?

[ljharb]

@noahleigh yes, that's a good point - the DOM is one of the places that makes it very hard to avoid mutation (which is part of why we use React at Airbnb). For cases like these, I'd use an eslint override comment: // eslint-disable-line no-param-reassign

[emilgoldsmith]

Sorry to revive a very old and dead issue but I'm really curious about this. So this solution for arrays seems very good:

@carpeliam by copying instead of mutating: array.map(obj => Object.assign({}, obj, { prop: true }))

But what if it's an object of objects? Would you do something like this:

const mutatedObject = {}
oldObject.forEach((obj, key) => mutatedObject[key] = Object.assign({}, mutation))
oldObject = mutatedObject

or just disable the eslint rule or do you have a neater option?

Because for example using lodash's _.map which works on objects still returns an array, and that's of course not desireable when you want an object out.

[ljharb]

@emilgoldsmith you'd do something like:

const mutatedObject = Object.entries(oldObject).reduce((acc, [key, value]) => {
  return { ...acc, [key]: { ...value, ...mutation } };
}, {});

[emilgoldsmith]

Hmm interesting. Thanks for the answer!

[lukemcgregor]

In the context of this does anyone have thoughts on immer which clearly violates this rule (see immerjs/immer#189)