Full Stack Developer, Speaker, Educator, & Thinkster.io Author.

Month: November 2019

App Module vs Core Module vs Shared Module vs Feature Modules in Angular

Angular Icon

Angular development best practices indicate we should break our applications into modules. Modules in Angular refer to a place where we group like components, services, directives, pipes, etc for our applications.

The easiest to think about would be Feature Modules we simply break these up by feature or domain. But what about the App Module, Core Module, & Shared Module?

What should we put into each of them? What components should live in each of them? Why do we need all of them? Let’s take a look at each of the types of modules and what they are used for.

App Module

Lets first take a look at the App Module in Angular. The App Module can also be called the root module. Every app must contain at least one module and that is the App Module. We launch our applications by bootstrapping the root module.

We want to keep our App Module pretty compact. There should not be a lot of content in the App Module or App Component. We want to encapsulate our application into domain-specific modules, the Core Module, & the Shared Module, which we will look into now.

Core Module

The Core Module is where we want to put our shared singleton services. So the services that we want only one instance of while having them shared among multiple modules should live here.

The Angular injector creates a new instance of a service for each lazily loaded module that it is provided in. We want to keep our singleton services in the core module so only one instance is ever created. We do not want to spread them out in our feature modules.

Another piece of our application that should live in the Core Modules are app-level components. A good example of an app-level component would be the navigation bar. Only the app needs to know about our navigation component.

We do not want to put components used throughout the application inside of the Core Module. We have the Shared Module for that and we will look at that now.

Shared Module

The Shared Module is where we want everything to live that is shared throughout the application. Components, directives, guards, & pipes can all live in the Shared Module.

An example of something commonly found in the shared module would be a loading spinner. If you have any other components that you want to be distributed throughout your application the shared module is where you want to keep them.

It is also common to import and export Angular built modules inside your Shared Module if you need to access them in multiple locations. Because Shared is imported into many of your Feature Modules it’s common to import/export Common Module or Angular Material modules. Import/Export the modules once in Shared Module and now anyone that imports Shared will have access to them.

Feature Modules

Applications commonly have multiple Feature Modules. Depending on the size of your application you may have A LOT of Feature Modules. Breaking things up into domain-specific areas can help in the long run for development.

One of the main reasons to break your features up into different modules is lazy loading. If you want to learn more about lazy loading check out the Angular documentation on Lazy Loading Feature Modules.

Laptop Code

Now you have a better understanding of how to separate your different modules in Angular. For more on modules check out the Angular Introduction to Modules.

Creating a C# ASP.Net Core API course now available on Thinkster.io

In June of this year, I began working on my first ever online technical course. It just got published! Check out my course published on Thinkster.io: Creating a C# ASP.Net Core API. I put in a ton of hard work to create the course and hope others can learn from it and enjoy it.

Link to Thinkster.io Course Creating a C# ASP.Net Core API

The course covers how to make your own API with C# using ASP.Net Core. It starts with the basics covering the GET, POST, PUT, & DELETE HTTP methods and expands into the more advanced cases. You will also learn about status codes, error handling & C# best practices.

The course provides you with the skeleton code for a space-themed API and contains four different exercises to reinforce and test your learning. By the end of the course, you will have your own fully functioning space-themed API written in C# using ASP.Net Core.

Basic knowledge of C# and the desire to learn is all you need to be successful in the course.

Brooke Avery and Joe Eames deserve a big THANK YOU for the support and help in developing this course. Expect more courses in the future. I think my next one will be on LINQ!

© 2020 Thomas Desmond

Theme by Anders NorenUp ↑