In this lecture, we are going to talk about a memory leak issue with our service memory leaking is
not a widely discussed topic among JavaScript developers.
It can often be overlooked when developing a large application.
Let's get into memory leaking.
In simple terms, a memory leak is when a variable is not on initialized.
Applications can have dozens of variables.
Some variables need to be available throughout the lifetime of an application.
Other variables can exist for a single moment.
Afterward, we can toss them away.
Whenever we define a variable, we are taking up memory or storage on a user's machine.
A memory leak can happen if we forget to destroy a variable in some programming languages.
Managing memory needs to be handled by the developer.
However, with JavaScript, the process is semi-automated, variables defined and functions are cleaned
up.
After a function is finished.
Executing JavaScript will destroy variables defined inside the function.
The properties in our classes are destroyed whenever a class is destroyed, whenever data is destroyed
in our app.
We release memory on a user's machine by releasing memory.
Other programs can take up the memory.
It's considered good practice to free memory whenever you don't need it anymore.
You may hear this process referred to as garbage collection.
It's a program that runs behind the scenes.
It'll periodically check if there are variables that should be freed.
As I said before, this process is semi-automated in JavaScript.
It's not something we have to worry about.
As often we can manually free memory by changing of variables value to null.
There are other ways to free memory by deleting a property on an object or removing an item from an
array.
Overall, it's not something we need to worry about as often with JavaScript.
Our model has a memory leak.
Can you guess what it is?
We are not unregister ring a model after it has been destroyed.
I'll show you what I mean.
I'm currently inside the app template file.
Inside our templates, we are loading the authentication mobile component by adding this element.
Angular will create a new instance of this component.
The authentication modal component will register a modal worth our service.
Simple enough, right?
What if we destroyed this component after creating it?
Let's see what happens.
We will add a N.G. if directive on this component.
The expression for this directive will be the following show model.
This property doesn't exist inside the components class.
Let's define it next.
Open the app component class file.
Inside the app class, we will add the show model property with an initial value of true.
Next, let's start toggling the model by toggling this property.
We will add the energy on in it lifecycle function.
Normally we would implement the interface for this function.
However, this test will be temporary.
We will remove the lifecycle function after we have fixed the memory leak issue.
Inside this function, we will call the set interval function.
The interval will be 1000 milliseconds.
Lastly, we will set the show modal property to its opposite value.
Every second, the model will appear and disappear.
The NGF directive will destroy a component if the expression evaluates to false angular handles, cleaning
up our components from the document.
However, our services will remain intact until another component needs them to better understand.
Let's inject bimodal service object by adding the constructor function.
Be sure to import the modal service object if it wasn't automatically imported for you.
Next, inside the interval function, we will log the model's property.
This line will throw an error because the model's property is set to private.
Let's change the access her to public open the model service file.
Change the private key word to public.
Once again, we shouldn't change the access.
The reason we're changing it is for testing purposes.
We will revert these changes after reviewing the error.
Let's refresh the page with the developer tools opened under the angular panel.
The authentication model component is being toggled.
Angular can manage our components.
Duplicate components are not the type of issue will encounter with Angular.
It can destroy the component on our behalf with one directive.
Whenever the component gets destroyed, memory is released.
Be released.
Memory can be allocated to other programs under the console panel.
We will start to experience some issues.
If you look inside any of the arrays, we will find models with duplicate IDs.
The original model is not being destroyed in our service.
Therefore, the browser is managing models that don't exist in our application anymore.
We have a memory leak in our app.
We should unregister a model if it is destroyed in the next lecture.
We will fix the memory leak.