So if everyone says Immutability is good, that means mutating objects is bad, right?
Here is my answer to this topic, it is contrarian and may also be contentious, but bear in mind its not the only answer, its just my own point of view.
Well, I’m glad you asked!
Q: What is wrong in mutating objects?
In fact programmers have been mutating objects for the past… er… 30+ years of application development. Its really the simplest paradigm for state management…
And why complicate things? When you have object
cat and it dies, do you really need a second
cat to track the change? Most people would just say
cat.isAlive = false and be done with it.
Q: Doesn’t (mutating objects) make things simple?
YES! … Of course it does!
Q: What if I have a new News object that has to be updated? … How do I achieve in this case? Delete the store & recreate it? Isn’t adding an object to the array a less expensive operation?
Well, you can go the traditional approach and update the
News object, so your in-memory representation of that object changes (and the view displayed to the user, or so one would hope)…
You can try the sexy FP/Immutability approach and add your changes to the
News object to an array tracking every historical change so you can then iterate through the array and figure out what the correct state representation should be (phew!).
Q: I am trying to learn what’s right here. Please do enlighten me 🙂
Fashions come and go buddy. There are 10 ways to skin a cat.
I am sorry that you have to bear the confusion of a constantly changing set of programming paradigms. But hey, WELCOME TO THE CLUB!!
Now a couple of important points to remember with regards to Immutability, and you’ll get these thrown at you with the feverish intensity that only naivety can muster.
1) Immutability is awesome for avoiding race conditions in multi-threaded environments.
Multi-threaded environments (like C++, Java and C#) are guilty of the practice of locking objects when more than one thread wants to change them. This is bad for performance, but better than the alternative of data corruption. And yet not as good as making everything immutable (Lord praise Haskell!).
2) Immutability can somehow avoid race conditions in the state of your app.
And here is the real crux of the matter, most (React) developers will tell you that Immutability and FP can somehow work this magic that allows the state of your application to become predictable.
This rather confusing claim simply means that the latest values assigned to a state object (defined by a single user operating within their browser) become predictable. Which is really no progress at all. Because you could have used a plain old mutated variable to track your state and you’d know you’re dealing with the latest information whenever you access it, and this will work with anything but React/Redux. Why? Because React is special.. and
this.state will do weird things in a React component if you accidentally mutate it. I’d rather see that as a reason not to use React, rather than to use immutability everywhere.
3) Race conditions are categorically bad.
Well, they are if you are using React. But they are rare if you pick up a different framework.
Besides, you normally have far bigger problems to deal with… Problems like dependency hell. Like a bloated code-base. Like your CSS not getting loaded. Like a slow build process or being stuck to a monolithic back-end that makes iterating almost impossible. Like inexperienced devs not understanding whats going on and making a mess of things.
You know. Reality. But hey, who cares about that?
4) Immutability makes use of Reference Types to reduce the performance impact of tracking every state change.
Because seriously, if you are going to copy stuff every time your state changes, you better make sure you are smart about it.
5) Immutability allows you to UNDO stuff.
Because er… this is the number one feature your project manager is going to ask for?
6) Immutable state has lots of cool potential in combination with WebSockets
Last but not least, the accumulation of state deltas makes a pretty compelling case in combination with WebSockets, which allows for an easy consumption of state as a flow of events… When done right this can make real-time apps easier to accomplish. Having said that, given the fact this is surplus to requirements in most cases, the amazing potential here will generally go unexplored in most projects.
Now for some advice, should you choose to accept it.
Now if you are fortunate enough to be able to make choices in your work, then try and use your wisdom (or not) and do what’s right by the person who is paying you. You can base this on your experience, on your gut, or whats going on around you (admittedly if everyone is using React/Redux then there a valid argument that it will be easier to find a resource to continue your work)… Alternatively, you can try either Resume Driven Development or Hype Driven Development approaches. They are also pretty cool.
In short, the thing to be said for immutability is that it will make you fashionable with your peers, at least until the next craze comes around, by which point you’ll be glad to move on.
And the reply!
Hello Steven, Yes. I had all these doubts when I considered immutable.js and redux. But, your answer is amazing! It adds lot of value and thanks for addressing every single point that I had doubts on. It’s so much more clear/better now even after working for months on immutable objects. – bozzmob