Object.freeze

[00:00:00]
>> Kyle Simpson: So what do we need? Your instinct might be to say because we're talking about immutability, aha! We need an immutable data structure. No, we don't. Because what we need right now is, we just need to say that this value is read only. And that is a different sort of a claim then asking for it to be an immutable data structure.

[00:00:25]
And I know that seems counterintuitive, but hang with me because we're gonna talk about what immutable data structures are about. And I'm gonna say, right now we're focused only on the claim. Could I say that this thing is read only? That it can not be mutated in any way, because I think a lot of times when people think, I guess I need a mutable data structure, actually what they need is just a read only data structure.

[00:00:50]
A data structure that can be read, but can not be written to and those are different than immutable data structures. So it turns out, it's built into the language there is a way to have a read only data structure pretty simple and that is to call Object.freeze. Object.freeze as you see on line 11 is telling that object you should change all of your properties to have the read only attribute on them so that none of them can be changed.

[00:01:19]
The object can't have properties added, it can't have properties deleted. It is, however, only shallow, so be aware that if you have nested objects of nested objects of nested objects of arrays you would have to freeze each one of those levels to get that same level of guarantee.

[00:01:35]
But in our simple case, where we have a simple, single layer object. A simple call to Object.freeze gives us the guarantee. But I'm actually going to make a slightly even different claim. I literally don't care if Object.freeze actually does what it's supposed to do. I mean it can be like an empty [INAUDIBLE].

[00:02:01]
The real point is that I am communicating something to the reader of the code at this point. It is less important to me that it actually be read only, and more important to me that the reader be able to know, I am saying you don't have to worry about this thing changing.

[00:02:20]
As a matter of fact, it'd be nice if the language gave us some sort of syntactic facility for that, maybe an operator when we make an object or when we pass it or something. They're not ever going to probably add something like this. But, you know, harebrained idea, but it'd be nice if there was even a lighter weight way than saying Object.freeze.

[00:02:37]
But basically what I want is an annotation that tells the reader, you don't have to worry, it's not gonna be modified. It's read only. You don't have to worry about it being mutated in some way that you don't expect. Another good part is that object freeze does actually do what it's supposed to do.

[00:02:56]
So it gives us not only the signal to it, but it enforces it from a runtime perspective. That if process order where to try to do something that it shouldn't, the whole program's gonna blow up and an exception is gonna be thrown. Now, the reason why I say I don't actually care about that part is, because it is vanishingly rare, that something like that, like trying to reassign to a property that was actually said is read-only.

[00:03:21]
It's rare that, that's been wrapped in some try-catch and gracefully surfaced to the user as a, oops, something went wrong. Because if that occurs, if you pass in a read only data structure to process order and process order is in the habit of wanting to mutate the thing, then you have a fatal, unrecoverable bug in your program.

[00:03:46]
>> Kyle Simpson: It's the kind of thing that we'd like a linter to catch for us and maybe depending on what kind of, you know, programming language or if you're using a type script or something like that, maybe you can get linter static checker to sort of tell you, about that problem.

[00:04:01]
But, if it passed in, as a read only, and then process order tried to catch it, that's gonna create a fatal error condition and you the developer gonna fix it. What I'm really concerned about is when we don't have those fatal errors, but we have those subtle crappy bugs that are really, really hard to debug.

[00:04:17]
The user's still able to check out but it charged them $1 extra on the order than it should have. And nobody can figure out where that extra dollar came from. Those are the terrible bugs, aren't they? They're the ones where there wasn't a fatal crash but it was still a bug and it's really hard to reproduce the conditions for that.

[00:04:35]
And one of the ways that we avoid those sorts of things is by telling the reader of this code or at least, whether we avoid the bug or not, at least make it easier to diagnose, as we tell the reader, you don't have to worry, the object didn't change at this point, it's not gonna change.