Immutibilty
Published: 2020-06-03 11:46:48


In JavaScript,  assignment of objects versus values must be understood. Did you know that all object assignments are by reference?

**[By Reference vs. By Value](https://www.google.com/search?q=javascript+by+value)**

When 'by reference' is fully understood, mistakes, **never happen.** 

If 'by reference' is *not* fully understood; then **mistakes always happen.**

```javascript

//a javascript object with name of john
let john = {firstname:'John', money:100};
// the first sign of trouble 
let jason = john
// Set first name to object name
jason.firstname = 'Jason';
// Nice now I have a Jason object with first name of Jason
``` 

**But Jason never will be John in real life, ever!**

```javascript
// why do this?
let jason = john;
// jason is only pointing to john!
```

This bug, caused by the developer; will have catastrophic consequences.

- Jason never deposited any money but has $100.00 (nice for Jason)
- John's first name is now Jason.
- The bank is totally confused
 
**Cascading the Bug**

```javascript
 
// Jason deposits another $100.00
jason.money = jason.money += 100;  
console.log(john.money) // prints out 200
// What? john doesn't have $200.00 either

```
- john now has $200.00 but didn't put in extra $100.00
- john benefits from this bug as long as he doesn't mind his new first name!
- Bank is really mad now, the auditors have called in investigators. 
- They find it was a developer issue, whose performance review is now in the tubes for this year.

As we can see, Mutation is bad! Right? 

Nope, the bad was in misunderstanding of how JavaScript objects work. Again, the root cause of the bug was a **developer error!**


A while back, a question about immutibilty was posted. {% post https://dev.to/jwp/what-s-so-great-about-immutability-3ppf %}

The best reason given was change detection. Either the pointers to the instances are the same or they are not the same. This leads to near instantaneous change detection for any two objects!

Instant change detection is wonderful; however, it alone does not justify mandatory adoption of the immutability pattern. 

Today we are seeing developers buy into this concept. They are for example, creating Components where immutability is enforced.

There is a newer [grid component in Angular](https://github.com/swimlane/ngx-datatable) that enforces immutability. Grids show rows, with each row containing multiple properties, which cannot be mutated!

Immutability means no property in any row of a grid can be changed! Instead, a new object must to be created with the change. This forces the view to show either a dialog to change it, or some other magical overlay thingy. Programmers must learn new ways to simply change a property value.  

You mean I can't just change a bank deposit field if it's shown in a grid and then save it?  Yes that's exactly the case with immutability. 

With today's super cheap Memory and ultra fast CPUS with multiple cores, making new objects is not really an issue. However forcing developers to adopt a pattern where it's really not needed doesn't make sense. 

**Summary**

Immutability is not mandatory ever! In real life, excepting for an alias, there's no reason to make one object the same reference as the other.  

Changing a property in an object to reflect reality has been going on for 50+ years. If our code mutates objects correctly, there's no worries. Just update the property and save it. 

Mandatory immutability is just a way to save unenlightened programmers from themselves. 👌