We've already looked at the JS Capabil, built in weak data structures, which are weak map and weak set. But if you want more low level control of weak references to build your own data structures or just want to gather a deeper understanding of how these data structures work underneath, then learning about the weak ref class is exactly what you need. Normally, when we assign an object to a variable, this is what JavaScript calls a strong reference, and since this is what we use most commonly, feel free to call it just a reference. We can use this reference to access the objects members. For example, the X and the Y properties.

Modern JavaScript comes with a built-in class called weak ref that takes an object into its constructor and then wraps it up into something that does not hold it using an assignment operator. What it does internally is actually more low level, and we do not have any special syntax for it. This is actually baked into the JavaScript runtime. Now, if you want to get access to the original object that the weak ref is wrapping, we actually have to use the D R F method provided on the weak reference. So as long as that original object has not been reclaimed by the garbage collector, we can access the X and Y, which should be 10 and 10. However,

if the garbage collector runs, for example, because of memory pressure and it wants to clear up as much memory as it wants, it might get rid of that original object that we passed to the B ref. However, any object that is truly referenced from our code, for example, by using the assignment operator will still exist. So REF will still have an object that has X and Y. However, we ref do DRE F might actually give us back undefined because the original object that we passed to V REF has been garbage collected. So unlike a reference where you can always use the properties that you want with

the V ref, you should always check if the response from D R F is undefined, for example, by using optional chaining. And that's pretty much all that there is to the weak ref. We have the weak ref constructor, which takes an object and the weak ref D a F method, which returns the object if it's still available or undefined if it has been garbage collected. As always, you could take my word for the fact that weak refs work, but seeing is believing and demoing a weak ref, letting go of its memory while a strong reference preventing garbage collection will give you some insight into how memory management works in JavaScript. Unlike our previous memory management tutorials, we,

we used special APIs within no js. Let's do the demo of the We Craft by using the Chrome Developer tools, and this will actually give you some insight in how you can profile and manage the performance of your own JavaScript applications. On the top, we have the performance tools with the memory checkbox selected, and at the bottom we have the developer console. Let's start recording to see what the memory profile of some code is going to look like. Within the console, we create this utility function called Create heavy, which creates an object which has a heavy property, which is going to be an array of 10 million items all filled with a rose

emoji. Next, we create three strong references To the objects that we create using this utility stored in variables A, B, and C. This should see our memory consumption go up because we've created some pretty heavy objects and this memory cannot be de allocated as long as A, B, C are pointing to those objects. Next, we create three more heavy objects, but this time we wrap them up with weak references. This means that while memory will be allocated, if there is ever memory pressure, then the garbage collector can jump in and free up the memory for these objects. The strong references A, B,

C will always contain the objects that point to those rose emojis. However, the weak re may or may not. Right now it seems that the garbage collector hasn't run, so the weak references do point to objects that contain the rose emoji. Now, let's push things in our favor a little bit by triggering the garbage collector manually by clicking the trashcan within Chrome developer tools. Since these objects were pretty large, the garbage collector has most likely reclaimed the memory for anything that was a weak reference, and our assumption is proved to be true. You can see the strong references still contain the rose emojis, however,

the weak references have all been played and they are now undefined. The garbage collector will be able to garbage collect the strong reference to objects as well if you were to assign A, B, and C to anything else like null values. So now if you're on the garbage collector again, we should be able to see a decrease in the memory consumption in the final profile that will be collected. And now for the moment of truth, the memory consumption actually looks exactly how we thought it would be. It starts off at a reasonable level, then it jumps up when we allocate those heavy objects and store them into strong references.

Then it jumps up again when we allocate more heavy objects and store them in weak references. But when we run the garbage collection, all of those weak reference to objects can actually get garbage collected and the memory consumption jumps down again. And finally, when we assign those strong references to null values, all of those can be garbage collected as well, and the memory consumption jumps down even further. As you mentioned in our lessons on other weak data structures, you really need to worry about weak references as objects and references that are used to hold their object normally live in the same scope and they get

garbage collected together. But it's great that JavaScript provides such low level control to its memory management while still keeping it high level enough that we aren't directly responsible for allocating and locating our own memory. As always, thank you for joining me and I will see you in the next one.