SD Tidbits
Published in

SD Tidbits

Modularity — the name of the game


Photo by Polesie Toys from Pexels

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 providers arrays

So, let’s switch to providedIn.

Injectable Decorator

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.

Home Page Component
Home Page Service

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.

Home Page Service + Book Service



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store