Mar 12
Modularity — the name of the game
Injectables
In the spirit of Spring cleaning, let’s talk about decluttering in Angular.
Angular makes modularity easy and simple to accomplish. Right off the bat, you can make a clear distinction between the view, model, and controller (processing) logic.
But, you know this.
So, when it comes to modularity, where does cleaning start? For example, when dealing with a library application.
Where are you providing the services?
When the application was a babe, the root app module’s providers array was one line of code. Now:
- it occupies a considerable chunk of the file
- some of the listed services are only being used by 1 module
- some of the listed services are in other
providersarrays
So, let’s switch to providedIn.
The @Injectable class decorator gets a config object that lets the app know a couple of things. The providedIn property tells the app how to make the service available via dependency injection.
The CatalogService will be available for all eagerly loaded modules via the root injector. So, all NgModules that are loaded on app initialization.
The HomePageService will only be available from the HomePageModule. If the module is never imported, the service won’t be available. This is a plus for final bundle sizes. This implementation is similar to using the providers array in a module — if you have more services for just this module.
An Ivy hallelujah…👇🏾
The CartService will be available for all eagerly loaded modules as a singleton…and to all lazy loaded modules as new individual instances.
This refactor should help with pruning providers arrays. You also get more readable code with no regression bugs — relatively 👀.
What are you subscribing to?
The library application needs to get a list of available titles from the Home page and the Catalog page.
So, it makes a HTTP request from the Catalog service and the Home page service. Additionally, it subscribes to each request from the components.
There are 3 glaring implications here:
- the Catalog and Home page components will have duplicate code to handle responses
- the Catalog and Home page services will have duplicate code to make the requests
- changes to the requests or responses will have to be done doubly
Does this get the job done? Yes, it does.
Is it ideal for modularity? mmmm…
Foremost, the components are doing too much processing at this stage, no?
A component should mostly maintain the view’s model. It can easily make requests to services with one liners. It doesn’t need to handle HTTP errors. It can handle falsy data.
Simply put, if you are going to subscribe to something in the component, subscribe to data rather than requests.
The Catalog service would also have a similar implementation to get book titles. However, pretty soon, there will be a BookService that can handle the HTTP particulars for the 2 services. Thereby, reducing code duplication and some complexity, while achieving more modularity.
