In this lecture, we will create a shared module for keeping our code clean and organized.
We already know ahead of time we will need to reuse the modal component.
In that case, we should create the model in a separate module.
It's common practice to create something called a shared module.
It's a module with generic directives, classes, pipes and components.
Developers will outsource generic features to a shared module.
This module can be imported into other modules.
This practice reduces clutter in our other modules.
You will see this type of organization in most projects.
We are going to write the code for rendering the modal inside a shared module.
Then if an area of our app needs to render a model, we will import this module.
Since the code for rendering a model is registered with the shared module, it'll be accessible wherever
it is imported.
Simple and clean.
We have two options for creating a module.
We can create it manually or use the SEELYE.
I think this really is the best route to go.
It will reduce the likelihood of an error inside the command line and the following command N.G. Generate
module shared.
We're already familiar with the energy generate command.
It's a command for generating files in our project.
In this example, we are telling the Seelye to create a module with the name shared.
We can call the module whatever we want.
However, it's common practice to use the name shared for shared modules.
Let's run the command.
After a few seconds, a single file has been generated.
Let's check out what was generated inside the rectory.
A new directory has been created, called Shared.
It's recommended to have dedicated directories to modules and the related files inside this directory.
We have a file called shared module acts.
The next thing we will do is create a component for our model inside the command line.
We will run the following command energy generate component shared model.
If we look inside the shared directory, the modal component file should appear under it.
We have two model components in our app.
Let me add some clarity as to the differences between them.
There are differences come from their responsibilities, the authentication model will handle the inner
content of the model.
It will not care about whether the model is being displayed on the page, whereas the mobile component
in the shared module will not handle the inner content.
It will focus on the visibility of the model.
Before moving on, we need to export the modal component.
By default, the Clia declares the component but does not export it.
Exporting must be performed manually inside the decorator.
We are going to add the exports array with the modal component passed in.
We're exporting the component to make it accessible to other modules.
Keep in mind, the shared module should define components, pipes and directives for different parts
of our app.
This module should be shared next.
Let's open the user module.
At the top of the file, we will import the shared module.
Lastly, we will add it to the imports option.
By importing the module, we'll be able to start using our reusable model in the next lecture.
We will begin separating the responsibilities of the models into their respective components.