One notable feature offered by angular2 is lazyloading, but what is lazyloading? And more importantly, do I need it in my Team project? and if so, how do I set it up? These 3 questions are what we are going to discuss in this post.
What is lazyloading?
It is known as “delayed loading” and responds to a design pattern based on delaying the loading or initialization of an object. Applying this concept to our angular project the following structure emerges: a separate project in modules (eg: app.module.ts) in which, among other things, the following parts are to be defined::
-
- The components we are going to use (declarations)
-
- The modules I’m going to use components for (imports)
-
- The services I will need (providers)
-
- …
Well, having this clear, we already know that a module is a package that has a whole set of functionality. Following this line, the functionality of a project should be separated into small parts, for example:
Admin User Module
- Statistics Module
- Common Module
- User Component
- Metric Component
- …
Customer User Module
- Common Module
- Friends Component
- Component Photos
- My Wall Component
- …
Statistics Module
- Status Graphs Component
- Search Graphics Component
- Active Time Graphs Component
- …
Common Module
- Navigation Component
- Login Component
- …
An important part of the above example is that a module can also contain other modules. Regarding the rest, we are already realizing that the following structure we have to think about from the beginning of the project, since it implies a very specific way of organizing our code.
Knowing this, it seems that the idea of lazyloading is already becoming clearer, right?, only the necessary modules will be loaded at the time we need them, i.e.:
If I enter as an administrator user, only the components of the administrator module will be loaded, neither the user components nor the statistics components will be loaded, only the components of the administrator user.
If I enter statistics as an administrator, all components of the statistics module will be loaded.
As simple as that, this frees the web project from loading all the files at the beginning, which will give us a more fluid feeling than if we load everything at the beginning. However, what we have been talking about brings us to the next question.
Do I need it in my project?
Here you can only be consistent with the project you have in front of you, lazyloading begins to notice when the volume of the project is large, however, it is not problematic in small projects. To answer this question you have to ask yourself the following questions
Does my project have expectations of being great?
-
- If you want a large and stable project, incorporate lazyloading, without any doubt, or think about it.
My project is not going to be big for now .do I need it?
-
- Keep in mind the following, if in the future the project is large and we want it to remain stable we must incorporate lazyloading and it will not be easy to restructure the code to separate it into modules, in some cases unviable.
Do I have the time to configure and a separate structure in modules?
-
- The reality is that it does not take much time if you start from the beginning with it, configuring the delayed loading of modules is not a great complication or interferes with the work.
How do I set it up?
I hope that at this point you have convinced yourself that incorporating lazyloading is a good idea and that you are already thinking about learning how to incorporate it in your project. In this part we will see how to configure a project to load modules in delayed.
The first thing is to generate so many modules, using the command ng generate module $module-name, like the parts you identify in your project, for this demo we are going to use the following module structure:
-
- App
-
- Admin
-
- Stats
-
- Client
-
- Common components
With the following load hierarchy:
AppModule
-
- Import-CommonComponentsModule
-
- Lazyload-AdminModule
-
- Lazyload-ClientModule
AdminModule
-
- Import-CommonComponentsModule
-
- Lazyload-StatsModule
ClientModule
-
- Import-CommonComponentsModule
Well, how do we represent this in our project? The first thing is to go to the highest module, in this case AppModule and it should look like this:
Well, as seen in the example above, the lazyloading configuration is done by configuring paths by referring to the module using the ‘loadChildren’ property. In this way we are already delegating in the admin and Client modules the management of components, that is, the delegated modules will already take care of managing their own components and their routes.
Now let’s go to AdminModule, our next module within this hierarchy, let’s see how it looks
As we can see, the configurations are very similar to those we have done in AppModule, we load the components we need and delegate the modules we want to load in a lazy way without complication so far no?
Well, so far the configuration of modules and now it only remains to move on to … develop our project, lazyloading has no more configurations! Great, Isn’t It? Well, we’re just missing one thing, one thing. How do we know if a module is loading in a lazy way? Very simple
The check would be done in the following way, we go to the browser, being on the main page we open the elements inspector and once there we go to the third tab ‘ ‘ Sources’, we should have something like this:
If we now address, for example, to admin we will observe the following change:
As you can see, a new file called admin.module.chunk.js which contains all the components, services, … defined in the admin module, separately, has not been loaded until we have not navigated to that route. If we change the path for example to client, we would have a new file called client.module.chunk.js with the contents defined in that module.
In conclusion, an excellent way to segment a project and control the load
