Immutable.js Overview

[00:00:00]
>> Kyle Simpson: In the interim, in any place where you have a data structure and it is important for you to manage the mutations to that data structure. You're gonna need a library that provides you an immutable data structure. And there are a couple of major ones out there that you will hear about.

[00:00:16]
Probably the most common of those is called the immutable-js, comes from the folks at Facebook. So if you wanna check out immutable-js, they've got a bunch of great documentation, and there's a huge community around it. It's a great library. There's another one out there that seems to be preferred by people from particular sects of the functional programming community.

[00:00:37]
Especially those that kind of come from like the closure and that sort of side of our programming community. That's called Mori, M-O-R-I. ClojureScript, which is the JavaScript subset of Clojure, the language, has immutable data structures in it. And what they did was extract those immutable data structures into a library, and they released it called Mori.

[00:00:59]
Has a different take on the way that it works and what the API looks like. But same general end goal, which is, give me structured mutation on my data structures. So here's an example. I create an immutable list of a couple of things. Now, it doesn't really matter whether those things like textbook and supplies are strings or objects, or arrays.

[00:01:20]
From the level of the data structure, the outside, all we're saying is, the presence of those in this list is what is immutable. If those things were objects, then they would still be regular old mutable objects. So, if you want to have deep immutability, you wanna prevent one of those sub objects.

[00:01:37]
Then you're gonna need to immutable data structures at every level. But I left it sort of deliberately general here. We don't know what textbook, supplies and calculator are on. But at this point, that's not our concern. They could be immutable-js objects, maps or something like that. Or they might just be regular old, plain objects or strings or numbers, or who knows, whatever.

[00:01:56]
But the point is, line six, when I say dot push, on an immutable data structure, an immutable list. It's not going to actually modify that list the way it would have with the normal array. Instead, we're gonna get back a whole new object. That's called updated items. And that new updated items object has all the same stuff as the previous one, plus the new objects having been added.

[00:02:21]
And that's why items.size is still two, it didn't get changed in any way, shape or form. It is an immutable data structure. And internally they've taken care of the optimization to have the pointer to be where it needs to be. So let's review what we've talked about here.

[00:02:38]
We started by talking about the idea of assignment mutability. Generally speaking, we're talking about the const keyword and whether or not it's gonna provide the benefit. Usually functional programmers try to minimize the amount of assignments anyway. So it probably shouldn't be the case that you have very many of those declarations.

[00:02:57]
But for the ones that you do have, you're generally gonna be doing them inside of small blocks. And the const keyword is not gonna provide much benefit for you. So maybe it's more appropriate to use a var or a let in those places, just so that you don't trip up the reader of your code.

[00:03:13]
My rule is, not that I don't use the const keyword, but that I use the const keyword only for things that are already, by their very nature, unchangeable, like numbers and strings. So I'm fine if you say const basePrice equals 6. But don't ever please, at least in my opinion, say const ARR equals and then use an array, because that is inviting the reader to get tripped up.

[00:03:36]
The real point that we should be focusing on is the value immutability question. And we have two different ways, actually three ways of thinking about that problem. One way is at the call site when we're gonna pass in one of those data structures. We should annotate it with something like object.freeze to say to the reader, don't worry about it, it can't be changed.

[00:03:56]
And if you need to do sort of a recursive object.freeze thing, make yourself a little helper and just use that helper everywhere. Use the little helper called read only that you pass in an object and it traverses an object, and makes it deeply read only. That's great. Whatever you need to do to annotate to the reader, they don't need to worry about that thing changing.

[00:04:20]
>> Kyle Simpson: Secondly, when you receive a data structure, no matter what, assume that it should be read only. And lastly, if you need to actually track changes to data structures, that's what you should be doing with an immutable data structure. Immutable data structures are ones that need to be mutated.

[00:04:41]
That's what we have to rewire our brains to think about. Because we usually think about immutability as it's not gonna change. And what we really mean here from a functional perspective is, it's things that need to change, but need to change in a controlled way.