DEV Community

Discussion on: Emulating standalone components using single component Angular modules (SCAMs)

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

I would say it scales very well. We are able to refactor our application more easily because declarables are not tied to an Angular module that sets up declarations and compilation scope for multiple declarables.

What's the repetition you noticed?

On a side note, this was the first step towards components with local compilation scope. There are two more techniques, albeit experimental, that we cam use today. I didn't cover them in article yet because I thought we would get a stable API for this with Angular Ivy. However, that is still in the far end of the roadmap, so feel free to revisit these old techniques youtu.be/DA3efofhpq4

Collapse
 
haydenbr profile image
Hayden Braxton

A large application has a lot of components. For each of those components, I now have to also create an NgModule for it and import any modules that export declarations that I depend on. So most likely, I'm at least importing CommonModule (for ngIf, async, etc) and probably some other ThirdPartyModule if I use third party components. So that's the first line of repetition.

As I move further up the component tree from UI-interaction related components to business related components, I'm importing more ngModules for all the lower level components I need, and likely still CommonModule and ThirdPartyModule. So the result is a lot of import { SomeComponentModule } from './some.component.ts' and a long list NgModule imports.

To quote the article "SCAMs mean more Angular modules since we will have one for every component, directive, and pipe in our application." This creates a lot of extra boiler code.

I can understand the value of refactoring: I can move the component anywhere and it already has all of the dependencies it needs, but I would also question how often that is a need.

Clarification question: Suppose I have some kind of compound component where I always use a combination of components in concert. Like, maybe I have something like:

<my-accordion>
  <my-accordion-section>
    <my-accordion-header>Section 1</my-accordion-header>
    <my-accordion-content>Some content</my-accordion-content>
  </my-accordion-section>
  <my-accordion-section>
    <my-accordion-header>Section 2</my-accordion-header>
    <my-accordion-content>Some more content</my-accordion-content>
  </my-accordion-section>
</my-accordion>
Enter fullscreen mode Exit fullscreen mode

If I wanted to follow the SCAM approach, there would be one module for each of these four components. So then anyone who wanted to use an accordion would have to import all 4 modules. Or would it be acceptable to create some parent AccordionModule that has no declarations and simply export all 4 component modules so that anyone who needs an accordion simply imports this single parent module?

Thread Thread
 
snowfrogdev profile image
Philippe Vaillancourt

The way I understand the SCAM approach and have been using it is not that you should literally have a module for every single component in your app. You should have one module for every single component that is reusable in isolation.

So, for instance, if I have a lazy-loaded OrderListModule that has a parent OrderListComponent and that parent has a child OrderDetailsComponent that is not reused anywhere in the app, I would just declare OrderDetailsComponent in the OrderListModule.

If I have a set of reusable components that are only meant to be used together, like in your example, I would also declare all of those in one module. If you look at the Angular Material project, that is how they do it.

Thread Thread
 
layzee profile image
Lars Gyrup Brink Nielsen

That would be a feature module.