🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Description

When sticking to the smart/dumb(presentational) components paradigm, user has no option to precisely control the implementation of lifecyclehooks in the generated TS code. Given that the default is implements OnInit, this leads to unnecessary post-editing (removing OnInit, or adding other hooks by hand). As you gain experience in angular, you are able to tell beforehand which hooks you're gonna need before you issue ng g c, but the CLI doesn't give you a way to fine-tune the generated code at the command level.

Describe the solution you'd like

Introduce --hooks flag, taking a piped string of hooks to implement, or a specific constant to include none. Examples:

ng g c mycomp --hooks none = ng g c mycomp -h
ng g c mycomp --hooks OnInit|OnDestroy|AfterViewInit

Pros:

• provides a "compositional" granular opt-in model (as opposed to --skip* model which presumes existing defaults)
• scalable (same syntax could also apply to directives, services, eg. ng g s myserv --hooks OnDestroy)

Cons:

• not a fast-track solution

Having a flag to control the implements part would allow user to create custom scripts to follow the smart/dumb paradigm in their workflow, such as:

ng g c --hooks OnInit|OnDestroy|AfterViewInit -s false
   // usage: npm run csmart -- mycomp (= create mycomp, specified hooks, styles in ext file)

ng g c --hooks -c OnPush -s true
   // usage: npm run cdumb -- mycomp  (= create mycomp, no hooks, CD OnPush, inline style)

Describe alternatives you've considered

I would gladly hear of one if exists.

Of course, the suggested flag --hooks (alias -h) is just an example - you might choose a different wording, such as --implements, however implements could suggest that user's custom or 3rd party interfaces/classes could be implemented too, while the option we discuss pertains to Angular lifecycle hooks only

A fast-track solution would be to provide --skipOnInit flag, but this is a non-scalable solution which I don't want to promote here.