In this lecture, we will fix the memory leak in our app by unregister during the motile.
It's going to be simpler than you think.
We will start by working inside the mobile service file.
Below the register function, we will define a function called unregister with one parameter called
ID.
The type of the I.D. parameter will be string.
The purpose of this function is to remove a model with the associated ID.
There are a couple of ways we can go about this.
Either way, we will need to loop through the array of models.
I think the easiest way of removing the model is by using the filter function.
We will call this function on the model's array.
The filter function will return a new array based on the array it was called on.
We can pass in a function to filter the elements in the array.
The function must return a Boolean value if we return.
True, the element will be added to the new array.
Otherwise, it will be excluded.
Let's pass it an arrow function.
We will reference each item in the array as element inside the function.
We will compare the elements Don ID property to the ID argument.
We want to check if they're not equal to each other.
As long as the IDs don't match, the model will be added to the array.
If there is a match, it'll be excluded from the array.
This solution should remove the model from our array.
We can move on to the next step, which is to call this function when the model is destroyed.
Open the authentication model component class file.
The authentication modal component registers the modal.
It makes sense to unregister the model when the component gets destroyed.
We can use lifecycle hooks to help us detect when the component is destroyed before the component gets
destroyed.
We will call the unregister function.
The service is already injected into the component.
We can move on to defining the lifecycle function.
First, we should implement the interface for type safety after the on init interface.
We will anthee on destroy interface.
Adding the implementation of imported beyond destroy interface from the angular core package.
Be sure to add it to the import statement if it wasn't automatically added.
Moving on, we will define the energy on destroyer function.
Inside this function, we all call the this model dot unregister function.
The ID of the model is authentication.
With those changes in place, the memories should have been fixed.
Let's check out the app in the browser.
Inside the developer tools, the council will continue to output the models away from our service.
If we look closely, we won't see duplicate models whenever the model is added back to the document.
The array is empty after the model is removed.
This is exactly what we wanted.
The browser doesn't have to care about a model that isn't in the document.
We fixed a memory leak in our program.
We should always consider how data is created in your app.
If you create data inside a component, the data will take up memory until the component is destroyed.
However, if we have a service, data and a service will persist, we should responsibly manage the
data in a service before I end this lecture.
I'm going to undo the changes we made to the components.
Open the app component class file.
We will empty out the class.
Next, we will remove the import statement for the modal service object.
Afterward, open the app template file.
We can safely remove the NGF if directive from the components.
Intermodal service file.
We will change the access of the motels property back to private.
In the next lecture, we will make one more improvement to our model.