by Balázs Tápai
How I built a customizable loading-indicator with Angular dynamic components
Recently, I wrote a blog post about creating a reusable loading-indicator component for Angular projects. The next step is making the indicator part customizable. But how exactly do you insert your component into the overlay? That is where dynamic components can help us.
Note: Since my previous blog post, I have refactored some parts of the library. Feel free to check out the git repository.
The use-case is that we have a really easy to use loading-indicator. By default, it has a spinner, and it can be triggered using the library’s decorator methods. However, our end user wants only “Loading…” displayed on the overlay. We can copy the logic and then replace the spinner with the text itself, but that would be rather redundant.
In order to be able to use dynamic components, first, we need a simple decorator implemented. This decorator makes it possible to inject our own component into the template.
We have to add this directive to our library’s NgModule. Then replace the spinner component inside the loading-indicator template with the following:
Now that we have this template, we need to do 3 things in the loading-indicator component.
- Inject the ComponentFactoryResolver into the component.
- Use the @ViewChild decorator to get our indicator-host.
- Load the provided component.
We need to load the component in the OnInit lifecycle hook. The OnInit hook runs after the first ngOnChanges(), and it is called only once. It is the ideal place to load a component dynamically into the DOM. We also need to clear the viewContainer reference during component destroy.
Let’s examine our ‘loadComponent’ method a little bit further. We want to provide our custom components using our configuration logic. When a custom component is not provided in the config, our indicator will be the default spinner component.
Then we use the componentFactoryResolver, to get the component’s factory. To be on the safe side, we clear our ViewContainerRef first. Then we create the component using the resolved factory, and we set our config values on the created instance.
Our end-user wants only a small text instead of a fancy spinner. A rather simple component would look like the following:
We provide it in our app’s main module, where we set up and configure our library. Adding the component into the ‘entryComponents’ array makes it sure that its factory can be resolved during loading.
From now on, we can replace the indicator component in any of our Angular projects, without the hustle of reimplementing most of the logic over and over again.
If you would like to learn more about Dynamic components, I recommend you to read: Here is what you need to know about dynamic components in Angular by Max Koretskyi
Thank you very much for reading this blog post. If you would like to try the above-mentioned lib out, you can find the package and instructions to install it here.