Angular Standalone Components and Their Impact on Modularity

A look at “Optional NgModules”

One of the upcoming features in the Angular framework will be “Standalone Components” (SC) or “Optional NgModules”. It will remove the necessity for NgModules.

There are many blog posts, articles, etc. about SC. This article answers a question that isn’t discussed that often: How will SC affect modularity in an Angular application?

NgModule contains the term module. When SC makes NgModules optional and maybe deprecates them in the long run, does that mean we will not have modules anymore? Given that Angular is an enterprise framework, and the Angular team’s continuous strive for stability, this would be an unexpected move.

I start with a summary of what SC are and what advantages they bring. Then I focus on the main question, namely if optional NgModules and modularity form a contradiction. The last part is about the best way we can prepare for SC right now.

The source code is available on GitHub.

If you prefer watching over reading, here is the video version:

1. What are Standalone Components?

Discussions around SC have been going on for several months in the community. Igor Minar, one of the key developers behind Angular, said that he had wanted to deal with NgModules since the very early beta version of Angular. This was in 2016. So, it was quite an event when Pawel Kozlowski posted the official RFC for Standalone Components on GitHub.

The key element in Angular is the component. Every component belongs to an NgModule which provides the dependencies for it. The property declarations of a NgModule’s decorator creates this relationship.

For example, if the component requires the formGroup directive, the NgModule supplies that directive via the ReactiveFormsModule.