WeakRefs & FinalizationRegistry

[00:00:00]
>> Maximiliano Firtman: Remember that we talked about weak set. And we talk also about weak maps? Well, from ES 2021, we can create weak references of every object, so we can create a weak reference and for that, we use the weakRef constructor we Pathan object and going back to the idea that we mentioned before, if you look at this code, how many objects do we have?

[00:00:32]
What do you think? Only those two lines, one option. The object is actually this one. That's the option, how many references?
>> Maximiliano Firtman: Two. But now we need to split in types of references, strong references. I have only one.
>> Maximiliano Firtman: That one, and weak references. We have one, weakRef.

[00:01:03]
So what's the deal here? If I do something like this. Now what would happen? I will not have a strong reference anymore, which will live in the future, in the near future, we don't know exactly when, into the removal of the object by the garbage collector. So then I will keep a weak reference that will point to null, so the weak reference will not keep that ties.

[00:01:38]
It says okay, if someone else, if no one else needs that object, okay. I'm okay with that, okay? I'm okay if that object disappears. That's what you're doing when you create a WeakRef. But you're thinking why is this important? Because as JavaScript developers, most of the time we have never thought about memory a lot.

[00:02:04]
When you're doing other things, when you're doing machine learning, AI, now you can run AI in the browser, you're using a lot of memory. Or when you're doing WebGL, you're doing br, augmented reality, you're using a lot of If memory and that moment if you don't release objects that no one else is using is a problem.

[00:02:30]
I'm probably thinking well having mine they're strong references and put the all of them in no, but sometimes you don't control all the references because you're passing objects by argument to the library should be your car, you're passing the object will from a lot of places, and you don't know what those libraries are doing.

[00:02:53]
Well now the idea is that if the library doesn't own the object, they will create a weak reference. So we can have better control, also, there are some situations that, again, I don't wanna spend too much time on this. This is memory management, but when you have object a pointing to object b and object b pointing to object a.

[00:03:19]
So, something like this. You have a, that has property. Let's call that property other than by default it's null and then we create b that has another property pointing to a. And after we create other b, I will say that a.other = b. Make sense? So now we have a pointing to b, b pointing to a.

[00:03:51]
Both strong references. So here comes the part where you can, if you have a lot of these situations, you can end up with memory issues, a memory leak. Including memory leaks, okay? Again, I'm not going to get too much into this, but to solve this problem, one of those references can actually be a weak reference.

[00:04:12]
So you create a weak reference of the other one, okay, to solve this problem. Well, after saying this, when you have weak references let me go back here. To actually use the object, you have to deref it, okay? So to use, for example, the message. So you see the message on the screen, Hello, world, you actually need to call deref from reference.

[00:04:44]
It's just how it works, okay? So because the weak reference is like an object that has a pointer to the real object. Well, deref will try to get into the real object because we know that the real object might not exist anymore because it's a weak reference. Okay?

[00:05:01]
Make sense? Any question? On weakRef? Again, if you're just doing a web app with a form, with the screens going in and out, you're probably not going to use weakRefs, okay? For when you are doing a lot of memory management, that's when this becomes important. Also when you are working with web assembly and you are calling or communicating with native code, this might make a difference.

[00:05:30]
And this typically comes at the same time with finalization registry, which is what? So when you create a new, to be honest, I don't think I like the name. They could create another name for that, but anyway. It's like an event listener for the garbage collector. Remember, the garbage collector is a process running with the JavaScript runtime.

[00:06:01]
That look through the memory for objects that need to be removed because they don't have any strong references anymore. Strong reference zero. So, in this case, we can actually say, hey, I want to create a new finalization registry and your register an object to it. And this is kind a description.

[00:06:26]
So meaning that you can know or you can do something when that object is being cleared by the garbage collector or is being garbage collected. Why do you wanna do this? This also has to do with, memory management. There are some languages. The one that I remember immediately are C plus plus Swift and Objective C.

[00:06:52]
I remember working with all of those. They typically have a via lock method in classes. It's kind of similar to that, but in JavaScript. They're ready to do something when an object is going to be relieved from memory. For that, you use finalization registry. What? It can be via locking other objects that you are connected to.

[00:07:17]
Sending message to a server, hey, we are getting released from memory, logging, what's going on, things like that. And after that object was released, at some point in the future, you should see null when you deref that weak reference. It's difficult to see it in action because we don't manage the garbage collector.

[00:07:46]
So I don't know when the garbage collector is going through and deleting those options. In Java, you can call. I think it's free as far as I remember is system.gc. It calls the garbage collector to say, hey, go now clean the garbage now, okay? But in JavaScript, we don't have at least not in a standard way.

[00:08:10]
So it may happen in the future because now the object has no strong references. The only reference is weak. And because it's weak, it's not actually holding that option. Okay, make sense? Again, it's for an advanced usage of memory.