We humans like dealing in absolutes. It's easy. Nuance is hard. Unfortunately for us, everything involves nuance. That's why we should question ourselves if we start to wonder if mutation is always bad.
Hey all, if you enjoy this article I’d love if you signed up for my free, weekly newsletter. 1,500+ other developers have already signed up and are leveling up their web dev skills with me!
The truth is mutation isn't always bad, nor is it usually bad. It just is. It's an excellent tool some languages give us to manipulate objects. Like with any tool, it's our responsibility to use it correctly.
What is object mutation?
Here's a quick refresher on object mutation. Let's say we have a person object:
const person = { name: 'Jarvis', age: 32 };
If we were to change this person's age, we will have mutated the object:
person.age = 33;
This seems innocuous, right?
Where mutation goes awry
Programming is all about communication and expectations. Mutation goes awry when the intent of an operation isn't clearly communicated and when a developer's (or machine's) expectations are violated.
Let's consider the following (bad) use of mutation:
function copyPerson(person, newName, newAge) {
const newPerson = person;
newPerson.name = newName;
newPerson.age = newAge;
return newPerson;
}
Why is this bad? Well let's look at what happens when we use this function in the wild:
const jarvis = { name: 'Jarvis', age: 32, arms: 2, legs: 2 };
const stanley = copyPerson(jarvis, 'Stanley', 27);
console.log(stanley);
// { age: 27, arms: 2, legs: 2, name: "Stanley" }
console.log(jarvis);
// { age: 27, arms: 2, legs: 2, name: "Stanley" }
Out expectations have been thoroughly violated!
In our copyPerson function, we accidentally assigned newPerson a reference to the same person object. Since they reference the same object, mutating newPerson also mutates person.
How do we fix this? We can do it entirely without mutation by copying the person object using the spread operator and simultaneously overwriting the name and age properties:
function copyPerson(person, newName, newAge) {
const newPerson = {
...person,
name: newName,
age: newAge,
};
return newPerson;
}
And that will work! But we can also make it work with mutation, and this is totally fine. Some might even find it more readable!
function copyPerson(person, newName, newAge) {
const newPerson = { ...person };
newPerson.name = newName;
newPerson.age = newAge;
return newPerson;
}
So wait, if this is fine, was mutation actually the culprit? No, it wasn't. It was our lack of understanding about how references work.
Mutability and popular front-end frameworks
Popular front-end frameworks like React use references for render logic. Let's consider the following example:
function App() {
const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });
return <PersonCard person={person} />;
}
In this example, the PersonCard component will re-render if person changes.
Actually, let's be more careful in our wording here: the PersonCard component will re-render person references a new object. Again, we can get ourselves in trouble if we mutate person rather than creating a new object.
For this reason, the following code will be buggy:
function App() {
const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });
function incrementAge() {
person.age++;
setPerson(person);
}
return (
<>
<PersonCard person={person} />
<button onClick={incrementAge}>Have a birthday</button>
</>
);
}
If we click the "Have a birthday" button, we increment the age property of the person object and then try to set the person state to that object. The problem is that it's not a new object, it's the same person object as the prevous render! React's diffing algorithm sees no change to the person reference and doesn't re-render the PersonCard.
How do we fix this? You guessed it: we just have to make sure we create a new object based on person. Then, we can either accomplish the task by mutating the new object or some other means:
function App() {
const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });
function incrementAge() {
const newPerson = { ...person };
newPerson.age++;
setPerson(newPerson);
}
return (
<>
<PersonCard person={person} />
<button onClick={incrementAge}>Have a birthday</button>
</>
);
}
If your instinct here is that mutating newPerson is bad because we're using React, make sure to check your assumptions! There's nothing wrong here: newPerson is a variable scoped to the incrementAge function. We're not mutating something React is tracking, and therefore the fact that we're "in React" doesn't come into play here.
Again, it's very important to recognize here that mutation isn't bad. Our misunderstanding of object references and the React diffing algorithm are what caused the buggy behavior here.
When is mutation good?
Now that I have discussed some scenarios in which mutation often gets blamed for buggy behavior, let's talk about when mutation really shines.
Clarity
Often, I find mutation to be clearer. One example I like to use is if we need to create a new array with one of the elements in the array updated. When working in React, I have often seen the following:
function updateItem(index, newValue) {
const newItems = items.map((el, i) => {
if (i === index) {
return newValue;
}
return el;
});
setItems(newItems);
}
And this works fine, but it's kind of confusing and probably a bit challenging to read for someone who isn't fluent in JavaScript array methods.
A more readable alternative, in my opinion, is to simply create a copy of the initial array and then mutate the appropriate index of the copied array:
function updateItem(index, newValue) {
const newItems = [...items];
newItems[index] = newValue;
setItems(newItems);
}
I think that's a lot clearer.
Working with complex structures
One of my favorite examples of where mutability shines is building a tree structure. You can do this in O(n) time all thanks to references and mutation.
Consider the following array thay represents a flattened tree:
const data = [
{ id: 56, parentId: 62 },
{ id: 81, parentId: 80 },
{ id: 74, parentId: null },
{ id: 76, parentId: 80 },
{ id: 63, parentId: 62 },
{ id: 80, parentId: 86 },
{ id: 87, parentId: 86 },
{ id: 62, parentId: 74 },
{ id: 86, parentId: 74 },
];
Each node has an id and then the id of its parent node (parentId). Our code to build a tree can be as follows:
// Get array location of each ID
const idMapping = data.reduce((acc, el, i) => {
acc[el.id] = i;
return acc;
}, {});
let root;
data.forEach((el) => {
// Handle the root element
if (el.parentId === null) {
root = el;
return;
}
// Use our mapping to locate the parent element in our data array
const parentEl = data[idMapping[el.parentId]];
// Add our current el to its parent's `children` array
parentEl.children = [...(parentEl.children || []), el];
});
How this works is we first loop through the data array once to create a mapping of where each element is in the array. Then, we do another pass through the data array and, for each element, we use the mapping to locate its parent in the array. Finally, we mutate the parent's children property to add the current element to it.
If we console.log(root), we end up with the full tree:
{
id: 74,
parentId: null,
children: [
{
id: 62,
parentId: 74,
children: [{ id: 56, parentId: 62 }, { id: 63, parentId: 62 }],
},
{
id: 86,
parentId: 74,
children: [
{
id: 80,
parentId: 86,
children: [{ id: 81, parentId: 80 }, { id: 76, parentId: 80 }],
},
{ id: 87, parentId: 86 },
],
},
],
};
That's really nifty and rather challenging to accomplish without mutation.
Key takeaways about object mutation
Over time, I have come to realize that there are a few key points to understand with respect to mutation:
- Often we blame mutation for our own lack of understanding about how references work.
- Popular front-end frameworks like React rely on comparing object references for render logic. Mutating older versions of state causes all sorts of headaches and hard-to-understand bugs. Instead of recognizing the nuance, developers will often avoid mutation entirely anywhere within React code.
- Mutation is an excellent tool when its usage is clearly communicated.
- Mutation is an excellent tool if localized (e.g., the mutated object never escapes a function).
Top comments (16)
This kind of thinking is somewhat flawed.
Objects shouldn't change without a name change? You mean like an object of me and my age or address should never change? Hasn't ever been an issue in C#, ever.
Objects shouldn't change in a context where the local logic doesn't expect it to. That's the gist.
In C# you are forced to do conscious decisions about mutability so certain behaviours are expected. Rust falls in the same place.
Yes this is exactly why mutation is never an issue in C# because the context is fully known. The same applies to Javascript. "Know thy context". Trouble happens in Javascript due to bad practices. Immutabilty works perfectly in proper context but is not a "single tool solves all" where frameworks require it.
Sorry but it's not at all the same thing. JavaScript doesn't provide immutability mechanisms at all. In C# you can specify "readonly" on object property and go to bed. In Rust you actually need to allow mutation specifically with "mut". In JavaScript you need to re-investigate the context, as anyone might inadvrtedly call the wrong function on the wrong thing. Better leave a whole lot of documentation on which functions use mutating constructs and end up mutating stuff themselves and hope everyone does flawless code review.
You missed my point which ultimately was that the immutable fan club became that way due to Javascript programmers not knowing context. It is a 10 pound hammer for a 1 pound problem. So much so the magical spread operators were invented that allow mutation and return a new array. Over engineering in my opinion.
I attribute the 'don't mutate gospel' to inexperience. It was accepted at face value in Js community solely because of opinionated frameworks like React.
So much so, that we now see entire component designs requiring its use.
In a poll here on Dev.to, I asked for comments on the goodness on non mutable design. The best answer was 'to avoid per element comparisons' to determine what changed in an array'. All other answers were weak.
We got by just fine mutating objects in C# for 30 years. So the new found non mutable crowd has little history to stand on.
Also JS didn't really have strong typing nor did users really understand by reference and by value. All contributed to traps.
It's all about perspective and experience. Either way works, but what I choose in the end is simply the right thing for my project.
This article is greatl!
I really appreciate this perspective, John. As I mentioned in the introduction, we often find ourselves clinging to dogmatic views based on some bad experiences or simply because nuance is hard.
I also think the “opinionated frameworks like React” part is more like a misunderstanding a lot of folks have about React. The truth is React works based on referential equality, so its only opinion on mutation is that you shouldn’t mutate an object if you expect React to detect that change and take an action based off of it.
Anyways, thank you so much for the thoughtful response!
My thoughts on React being opinionated is based on how it demands its own way of doing things. For example just look at how it did styling. React is 20 times less opinionated than Angular which is good. The advent of webassembly brings all discussions like these to an end. We now have the ability to write entire websites using c# and it's huge set of class libraries. Cool
Object reuse as a pattern of shape for mutation is just ridiculous. It violates SRP and is always by reference. Thus the birth on non mutable to me was based on malpractice all along.
When a framework dislikes creation of new objects and instead tries to copy and change, it has a fundamental issue in allowing it to happen without warning. Newbies fall on this trap often.
No what I meant was 25 years of programming experience with no issues with mutating objects speaks volumes.
All the non mutable stuff has only 1 great attribute; which is simply a comparison of two references to instantly detect change.
This same thing has been possible for more than 25 years now in .Net
You are explaination is save alot of time in debugging when I work in JS.This artical is freaking cool.
Thank you, I really appreciate that!
Ok list some advantages to immutabilty.
As for Haskell is it in top 5 or 10?
The 7 articles shown are not absolute truths but are presented that way. Total hype.
I prefer not to mutate the object in any case.