This course has been updated! We now recommend you take the Functional-Light JavaScript, v3 course.

Check out a free preview of the full Functional-Lite JavaScript course:
The "Immutability" Lesson is part of the full, Functional-Lite JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

To a functional programmer, immutability refers to a variables ability to be changed. Kyle illustrates this by explaining the difference between using the “const” keyword and using Object.freeze().

Get Unlimited Access Now

Transcript from the "Immutability" Lesson

>> [MUSIC]

>> Kyle Simpson: The next thing we want to talk about is immutability. Now, immutability, mutation, immutability means non-mutation, non ability to, non ability to mutate. But this term evokes different things in people's heads. So I wanna show you one thing that is strictly speaking immutability, but isn't exactly the same thing as what a functional programmer means by immutability, okay.

[00:00:32] So if I declare a variable called x, if I say var x = 2, when I try to change it as I do on line 2, it's allowed. But if I declare a constant, const being a new keyword added in the ES6 version of JavaScript. And I try to change it on line five, that will not be allowed.

[00:00:49] If I'm in strict mode, it'll throw an error. If I'm in non-strict mode, it'll simply ignore the operation and not allow it to occur. So a lot of people say, well, const gives us immutable values. And that's completely and utterly false. The const keyword is not about giving you immutable values.

[00:01:08] It is about giving you an immutable assignment, or to be a little bit more programmer speak about it, it's an immutable binding. To a value. So what we mean here is that Y can never be reassigned to some other value. But we're actually not saying anything at all about the value itself being unchangeable.

[00:01:26] In fact in JavaScript primitives are by definition immutable. The value three can never actually be changed to mean something different than three. And a string, even a string, we might think of as being a mutable thing, because you might think of, I could go and change a character, no you can't.

[00:01:42] Strings, primitive strings, are immutable, primitive numbers are immutable, primitive booleans are immutable, so the const keyword actually has nothing to do with declaring a mutable or immutable value. Any more than var does. Var and const are controlling the assignment, or the binding of a variable to some particular value.

[00:02:03] This is illustrated on line seven. I do const z and I give it some object. Now, we know probably, most of you, that. Variables that hold values, which are non-symbol primitives, that's objects, arrays, functions, those are always held by reference, rather than by value. So z is actually a reference to the array, rather than holding array itself.

[00:02:25] And what we're saying here is only that z will never point to any other array than exactly that array. But we're not saying anything at all about the nature of the array. In fact, as we see, line eight would not allow us to change z to point somewhere else, even to a different array.

[00:02:45] But we can reach into the contents of z and change them all day long like we do on line nine. So const is not declaring an immutable array, it is declaring an immutable variable called z bound to that particular array by reference. So I want to make sure we clear that up and I've written some blog posts about this if you wanted to search on consts and get a [INAUDIBLE], you'll find a blog post about that but it's really important not to allow those two things to get messed up in your mind.

[00:03:16] If I wanted to declare an immutable array, it turns out there is another utility which is Object.freeze. Object.freeze the utility built in as of ES5. It reaches into an object, and at the shallow level only, that is the top level of all of its properties, it makes all of those properties Read Only.

[00:03:38] In an array, that means all of its numerically indexed positions. In an object, it means all of its named Properties. It makes all of those property assignments read only. It's kind of like applying const to each of those properties retroactively. It makes the properties themselves bound immutably. But it doesn't say anything at all about the values that they're pointing to.

[00:04:01] So if I had an array with an array inside of it It's not gonna make the array inside of it frozen. It's just simply gonna say that array has to always be in that particular position in the outer array. So object.freeze is the way of doing shallow immutability.

[00:04:17] If you want more sophisticated immutability, there are all kinds a, there are several really, really good libraries. Some stuff that has come out of the closure script world, and Facebook. There's an immutable, I forget exactly what it's called. But there's an immutable data structures library written in JavaScript that gives you immutability by default.

[00:04:38] It's very powerful, very useful. But I just want you to know that the built in language utilities are really not quite exactly the same thing as what's meant by those. Const is all about immutable binding, an immutable assignment is really the best way to think about it. An object that freezes about a shallow set of immutable bindings at the property level.

[00:04:56] Yes?
>> Audience: So other than objects of threes is making it computable. So what is really there?
>> Kyle Simpson: Yeah, that's a fantastic question. The question is if object dot freeze is all about making the value immutable, what is const doing. Const is saying that W will always and forever.

[00:05:16] Without any chance of being incorrect, it will always point to that exact array. So I cannot do line 12, I am not allowed to make w point somewhere else. That's all counts the same. Now just as a side note since you brought up the question, between the two, between making the value itself immutable, and making the binding immutable.

[00:05:38] Are there different value propositions here, are there different benefits to our code? Many people are of the opinion that the benefit of cost is gigantic in their program because their concern seems to be I don't know whether or not a variable's gonna get changed. But I actually think that that's completely a mischaracterization of the issue.

[00:06:00] Cuz I actually think the real problem that we have is not that our bindings are getting change but there are values are getting change out from underneath us. And here's why. Cuz bindings are always localized. There always within the program that you can see immediately in front of you.

[00:06:13] Even if it's a thousand lines long it's always within the program that you can see. And you can lexically analyze it, values are portable. They can be shipped elsewhere and if you can ship a value elsewhere and somebody can change that value that's a much bigger problem. That's an action at a distance problem.

[00:06:29] So in the world of immutability, immutable bindings to me are not all that useful or interesting. Immutability values are a lot more interesting and const has nothing to say about that.