SharedModule best practices in Angular7

In this post we’ll examine how to make our Angular modules future-proof. We’ll see what exactly should go into a SharedModule and how the rest of our application integrates with it.

A SharedModule is just a concept of structuring your application – there’s no built-in class in Angular for its functionality.

It saves you from constantly reorganizing your modules and components.

Here’s the deal: when you start a new Angular project your second step (after generating the template) is to add a new empty module. By convention we’ll call it SharedModule. You do exactly two things in it:

  1. Import and re-export dependencies for other modules (CommonModule, FormsModule, Angular Material or Primeng modules, etc.).
  2. Declare all dumb, reusable components, pipes and directives here and export them.

And here’s what you don’t do in your SharedModule:

  1. Declare services. They don’t really belong here. If they are application-wide singletons then they’re going in your CoreModule (which we’ll explore in a future post). If they are feature-specific then they’ll go to the feature module where you require them.
  2. Add business logic. Everything in your SharedModule is meant to be used by one or more of your feature modules. That means they must be dumb and generic as hell, so you don’t limit yourself when you need to use them.

If you’ve an existing project adhering to these conventions would be much harder. However it’s worth restructuring, because eventually you’d get circular dependencies.

Let’s see a super-straightforward SharedModule example:

As you can see we do the two things outlined above. First we import commonly used Angular modules required by other modules. Again, SharedModule is dumb as hell, it won’t really use most of these modules.

Then we declare our pipe (for the sake of brevity I only added one) and export it, so that other modules can work with it.

That’s all our SharedModule is and does.

Other modules and the SharedModule

All other modules in your application (RootModule, all your feature modules) can potentially import and depend on the SharedModule. The SharedModule typically won’t depend on your application modules, rather on 3rd party libs.

Recap

A SharedModule saves us from two types of Angular pains:

  • Maintaining a module dependency list in each and every module we have. When you add a new module dependency you just add it to your SharedModule and be done with it.
  • Having to worry and figure out circular dependencies between our own modules. By moving every pipe, dumb component and directive to one place we greatly eliminate potential circular dependencies.

Source code

I’m maintaining and developing a repo on GitHub. It contains Angular7 best practices. Follow this link to the relevant part of the code.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s