There are many posts about SC but this article answers a question that isn’t discussed that often: How will SC affect modularity in an Angular application?
Join the DZone community and get the full member experience. Standalone Components will make NgModules optional. This will not affect the modularity of applications in any way, because one should use libraries for modules and not the NgModule. 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 SCs 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: 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 a NgModule which provides the dependencies for it. The property declarations of a NgModule’s decorator create this relationship. For example, if the component requires the formGroup directive, the NgModule supplies that directive via the ReactiveFormsModule. The same rule applies to the other visual elements which are Pipe and Directive. For the sake of simplicity, these two are included when we talk of a component. This isn’t just extra overhead. Given that additional link between Component and Module and the fact that a NgModule can declare multiple components, it is not so easy to figure out which dependencies a particular component requires. Besides components, there are also Services to consider — and three different ways how to provide them. The NgModule can do it, the component can do it, or the Service could provide itself via the providedIn property.
