In this lecture, we going to talk about our problem with our model.
It has to do with a concept called single tents.
Before we talk about singletons, let's check out the problem in my ED. I have the mobile component
class and navigation component class files opened inside the constructor function of both components.
We are injecting the modal service object.
The object being injected is the same instance in both components.
If the objects were two separate instances, our model wouldn't work.
Every time we inject the modal service object, it'll be the same instance.
It doesn't matter how many times the object gets injected.
By having the same instance, we can toggle the same property.
The changes to their property are communicated to both components.
This behavior works great, but it does present a problem.
Let's open the authentication model template file.
I will minimize the first model below the first model.
We will create another app model component.
Inside this component, we will pass in a paragraph element with some dummy text.
We have two models, which model do you think will appear when we click on the login link?
Let's find out.
Refresh the page in the browser.
If we click on the logon link, both models will appear.
This behavior isn't what we wanted.
Models should open independently.
The problem lies with our service.
The models rely on the same instance of the model service class to understand why.
Let's talk about singletons.
A singleton is a design pattern in the programming world.
It's when a single instance of a class is given to an application, it's a programming practice adopted
from various languages.
Technically, nothing is stopping us from creating multiple instances.
If we want to follow the singleton pattern, we must always make sure there's one instance of a class
available.
Luckily, we don't have to develop such a system.
By default, Angular will treat services as single tens.
If our app needs an instance of a service, Angular will check if one exists already.
It will return the instance.
Otherwise, it'll create a new instance.
Therefore, our components will always use the same service.
This is why we never have to worry about working with two separate instances in our components.
In some cases, you may hear services described as a single source of truth.
Services are great for storing data components can reliably retrieve data from services.
If the data is updated, the changes are reflected in all components.
We have one reliable source of information, while convenient.
We will run into some problems.
Our model should have separate data.
We have two solutions for solving this issue.
We can force angular to create multiple instances of the modal service object.
However, I don't think that will be necessary.
Instead, we should continue to have one model service object.
The object should be able to manage an array of models.
I think that's more feasible and simpler in the next lecture.
We will get started on this implementation.