DEV Community

Don't stop Mutating

Stephan Meijer on December 16, 2020

I recently came across a tweet by Simon Høiberg that basically forbids you to use delete. The reason for this? "You don't want to mutate the existi...

Read full post

Jack • Dec 16 '20

I think this is quite a dangerous thing to encourage. In your example, fetchUsers could be bringing the data in from anywhere, it could be caching the result, it could be returning a hard-coded value, etc.

If you mutate the resulting users, what if another part of your code is also using it in order to get a list of ages? This would completely break it.

Immutability for the purpose of avoiding bugs is so much more important than readability or performance.

The real readability problem in your examples is that there's no natively elegant way to omit a property. Wouldn't you agree this looks nicer with a basic helper method?

const users = fetchUsers(100).map(user => omit(user, 'age'));

Stephan Meijer • Dec 17 '20

Sure, helpers help. Please understand, my examples are contrived examples. I assume that fetchUsers fetches data from a remote origin. An API call so to say. Should I have mentioned that in the article?

Your comment is valid. But that does not make my article invalid. I also don't want to encourage mutating data. I want to encourage people to see that there is a valid scenario for both ways. I wish people to stopped banning half the language, simply because they:

find it hard to grasp
think it's prone to bugs
think the new way is better

Immutability for the purpose of avoiding bugs is so much more important than readability or performance.

That can definitely be a good argument to make something immutable. And honestly, when working on the frontend, it often is. On the other hand, I'm also working on the backend, with geospatial data (geojson). When I run geospatial operations, such as geometry simplifications, mutating objects is WAY faster. It has a noticeable impact, that we confirmed by profiling real requests. When someone submits a form to my backend, and I just normalize/simplify that data before I send it to the database, it makes zero sense to do it in an immutable way.

My goal with articles like this isn't to encourage anything else than to open the readers eyes. "There is a valid use case for each and every function.". A lot of articles push readers in a specific direction. And (junior?) developers are very sensitive to that and start refactoring stuff right away. Only to come back to it years later.

Jack • Dec 17 '20

I 100% agree that the developer community is sometimes too opinionated and that everybody should be doing things a certain way. And there are of course instances where mutability is fine, even preferable, usually when you're writing internal code where you fully understand the implications of mutating data.

Your snippets have a good example of this. You're mutating an array by pushing to it, but you also created that array yourself directly before, so you have confidence that mutation won't cause any bugs.

For me I tend to do immutability-first and then think "what benefit would this have if I made it mutable?"

bravemaster619 • Dec 16 '20

You shouldn't have included projects attribute in the first place.

Anyways, deleting something somewhere in your code will cause unpredictable behavior in the long run.

You better leave original object as it is, because mutating objects WILL affect other parts of your code.

I agree on the second example (Unpredictable behavior) but the first one is kinda misleading. I would say.. Readability vs Maintainability

I will definitely choose this way:

const users = fetchUsers(100);
const newUsers = [];

for (let i = 0; i < users.length; i++) {
  const { age, ...newUser } = users[i];
  newUsers.push(newUser);
}

Stephan Meijer • Dec 17 '20

Yes, in the perfect world, projects wouldn't have been there in the first place. Unfortunately, we don't live in the perfect world. Sometimes we use external API's, and get more data than we need. Sometimes, we fetch data from MongoDB, and deleting a bit of data is easier done on the backend than it is through aggregation piplelines.

You better leave original object as it is, because mutating objects WILL affect other parts of your code.

No, it doesn't have to. If the mutation is abstracted away, there is no issue (my getUsersWithoutProjects example). And that's the point of the article. It really isn't that black and white.

I will definitely choose this way:

And that's okay. Everyone has their own preference. The fact that you choose this style, doesn't make someone choosing the other wrong.

bravemaster619 • Dec 17 '20

Sometimes, we fetch data from MongoDB, and deleting a bit of data is easier done on the backend than it is through aggregation piplelines.

Yeah, maybe it's easier to do in frontend. BUT you need to do in BACKEND. For the sake of security and performance. Right?

If the mutation is abstracted away, there is no issue (my getUsersWithoutProjects example)

I already said that I agree on getUsersWithoutProjects.

The problem lies in this one:

const users = fetchUsers(100);

for (let i = 0; i < users.length; i++) {
  delete users[i].age;
}

Stephan Meijer • Dec 17 '20

THANK YOU! It's truly nice to see that some people get it.

I'm not here promoting mutability or immutability patterns. I'm here to open eyes and make developers understand that they have to make a choice on a case by case basis.

Taha Ben Masaud • Dec 16 '20

If readability is the main concern of this article, I'd simply wrap the non mutating code in a delete function. Many libraries, such as lodash, provide this.

Stephan Meijer • Dec 17 '20

It's not. The main concern of this article is that too many of us (/other articles) lack nuance, and try to push developers in a single direction. While development isn't that black and white.

The TLDR is in the last paragraph:

Programming isn't black and white. We can't just ban half the keywords or native functions because they "feel wrong". There is a valid use case for each and every function

Taha Ben Masaud • Dec 17 '20

That is quite a statement. I'm not aware of any credible advice out there where the reasoning revolves around "feel wrong".

Mutation is definitely bad from my experience. While I understand where you come from, the advice in this post does not offer credible proof that promoting different styles is more important than actually following best practices.

Stephan Meijer • Dec 17 '20

Mutation is definitely bad from my experience.

Expressions like that are the reason I wrote this article. Mutating data is not "definitely bad". There are very valid scenarios where you want to avoid immutable patterns. And that's what I tried to explain in this post.

It's unfortunate that I didn't get this message expressed more clearly.

Taha Ben Masaud • Dec 18 '20

Mutation can only be beneficial because of machine code and computer architecture.

In an ideal world, e.g. higher level language, mutation should be avoided unless the developer really enjoys debugging.

It's clear you're stubbornly convinced that the wider community is at fault for sharing best practices; that I can do little to change.

Stephan Meijer • Dec 18 '20

It's clear you're stubbornly convinced that the wider community is at fault for sharing best practices;

Thank you for the kind words.

I like to think that I'm stubbornly convinced that I'm slighly frustrated by the unnuanced "best practices" I find on the web, that are blindly followed as the "only truth" by a bit too many developers.

Thorsten Hirsch • Dec 16 '20

I agree with you in all your examples. But in general I think "don't mutate" is a good advice (it doesn't say "never mutate").

Stephan Meijer • Dec 17 '20

Ooh, I definitely agree. Most of the time, immutable code is fine. Maybe even preferred. I simply try to make a sound against the unnuanced pushing that starts to take overhand on the web. I hope to make especially junior developers realize that they have to make decisions. And that banning half the language because it's "the old way" isn't the solution.

Jacob Evans • Dec 16 '20

I really appreciate the "this article isn't telling you what to do" feel you make sure to emphasize while still making a sound argument for your perspective on the issue!

Stephan Meijer • Dec 16 '20

Thanks, Jacob! 😊