Your Thoughts About Immutable Data
Tags: programming, discuss, javascript, react
Published: 2019-02-15 14:32:03

---
title: Your Thoughts About Immutable Data
published: true
description: A series of discussions about trending JS patterns. This week's topic was Immutable Data.
tags: programming, discuss, javascript, react
series: What Do You Think?
---

This week 8 devs made 14 comments about immutable data. Big thanks to all of you!

{% link https://dev.to/solkimicreb/what-do-you-think-about-immutable-data-118d %}

---

### My Impression

In general, you favored immutability over mutations and I was the sole 'antagonist' of the thread. There were two distinct uses cases mentioned.

Some of you wrote about immutability as **a way of thinking** and building whole apps. Unsurprisingly, these comments leaned towards **functional programming** and mentioned **clear data flow and increased code quality** as benefits in exchange for **added complexity**. A commenter quite nicely described these apps as **'data flowing through a pipe of transformations'** and mentioned that badly implementing this model can make things unnecessarily complex.

I have to agree with this, embracing this mindset is not an easy task. Don't give up or judge early if it seems messy on the first try, but keep trying until it makes sense.

Others brought up stories where **locally applied immutability** helped them. In these cases, immutability fixed issues with **unexpected mutations** of long living objects. My favorite example was a story of mutating events, which the event bus reused later without mentioning this in the docs. Moral of the story: you never know who else keeps references to your objects, always be suspicious towards third-party libs if you work with mutable data.

On the practical side, you mentioned **testing, memoization, and time travel** as areas where immutability really shines.

As the contra team, I mentioned the strictness as the biggest turn-off. I like to 'hack around' and I usually feel bad when I am **forced into a set of best practices**. The example I gave was about a (mutable) state management lib that I maintain. A big chunk of the issues are about very basic operations - like getting / settings values or applying (async) side effect. I always explain to simply use `obj.prop`, `obj.prop = value`, and async functions which the issuers are already familiar with. They are too afraid to even try them though because of their functional background.

Ultimately I think all of the comments were high quality and constructive. I was also hoping for some junior opinions though. Your comments matter, don't be afraid to express your initial thoughts, ideas, enthusiasm, or frustration.

### About the Future

This was the first post of the series and I realized I will have to change a few things: 

- I tried to avoid direct quoting in this summary but feel free to PM me if I should remove something. Next week I will add a disclaimer about the possibility of linking / quoting comments. I will never quote anybody in a negative context.

- In the future, I will bring up topics on Mondays and write summaries on Fridays. Sorry for the short commenting window this week.

---

Next week's topic will be *types*. See you on Monday!