Every time I am about to add a component to an Angular application, I feel like there is a bunch of people arguing in my head.
- Does it deserve a new
NgModule? - Will we re-use it soon?
- Who cares, we will refactor that when needed anyway.
- Yeah! But even with a great IDE, how straightforward is the refactoring?
TL;DR
There’s a new schematic to generate Single Component Angular Modules.
yarn add @wishtack/schematics
yarn ng g @wishtack/schematics/scam hello-worldWhere It All Started
A while ago, I caught this Pull Request https://github.com/angular/angular/pull/27481 from Minko Gechev which shows that the Angular team might make NgModules optional in the future.
It inspired me to experiment a new tagged template based syntax.
The current problem with this approach is that in addition to involving a new syntax, we will have to wait for optional modules support.
By the way, here’s Igor Minar’s (Angular Core Team) reaction about my previous post and optional modules:
In the meantime, we have to consider another way to solve this situation.
NgModule Refactoring Hell
One of the main challenges with NgModule is refactoring.
Given the following cute and tiny little module:
@NgModule({
declarations: [
SandwichFormComponent,
SandwichPreviewComponent
],
imports: [
MatButtonModule,
MatCardModule,
ReactiveFormsModule
]
})
export class CuteLittleSandwichModule {}It is already a challenge to move SandwichFormComponent to another module.
For instance, it is hard to tell if MatButtonModule & MatCardModule should be kept, moved, or duplicated to the new module.
SCAM!!!
What if we created one module for each component?
That is what the SCAM backronym means. It stands for Single Component Angular Module.
SCAM stands for Single Component Angular Module
As far as I know, this term was coined by Lars Gyrup Brink Nielsen in his article about Tree-Shakable Component and Optional NgModules.
I loved the concept so much that I created a simple schematic for that.
You can use it right away like this:
yarn add @wishtack/schematics
yarn ng g @wishtack/schematics:scam sandwich/sandwich-previewThis will generate the following file structure:
app/
sandwich/
sandwich-preview/
sandwich-preview.component.ts|html|...
sandwichdirectory is just for regrouping components, there is nosandwich.module.ts!
SandwichPreviewModuleis insidesandwich-preview.component.ts.
🧹 Say bye to .module.ts
In a response to this article, Alex Rickabaugh from the Angular Core Team suggested to just move the NgModule to the .component.ts file and simply get rid of the .module.ts.
It totally makes sense for two reasons:
- The component’s directory will be less cluttered.
- It should naturally discourage us from adding anything else to the module.
What about directives & pipes
Well, same applies for directives & pipes. SDAM & SPAM?
WebStorm Auto-Import
For those who are worried about having to import lots of modules, you should definitely try the latest version of WebStorm as it will automatically auto-import modules while you are writing your template. Ain’t that crazy… when you think back to that time when selector auto-completion was something! 😱
For the moment, I am not aware of any similar feature on VSCode but I am sure it will come soon 😊
The source code & documentation are here.
What about shared modules and routed modules?
SCAM is nice but we might still need some shared modules and routed modules.
Wanna know more about this? Here’s another article about this topic.
Check it out!
If you want to learn more about Angular and if you can read French (or if you don’t mind using google translate meanwhile I translate the content), you can have a look at our FREE Angular Guide https://guide-angular.wishtack.io/.
