Show Menu
Cheatography

Angular Structures Cheat Sheet (DRAFT) by

Things that might be nice to know when setting up an Angular project.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Project setup

Keep things together in modules. All pages, compon­ents, routes, valida­tors, services that go with that module stay with that module.
Pages are container components, they are children of the root component.
Only services get injected into container compon­ents, these services will have access to persisted data.
Other components will most likely be pure components, they get all their depend­encies through @Input directives and emit all changes to their parent through @Output direct­ives.
Storing the routes in the module (as a routing module), saves you time tracking it down whenever you need to make changes.

Project setup commands - sample

# When setting up a new project think about how you want it to look. Make a short list of commands to set up your project. Open the new project in your IDE, if things do not feel right, adjust your list and run it again. I have added an example below.

ng new sample
ng g m core
ng g m core/modules/homepage
ng g c core/modules/homepage/containers/homepage
ng g m core/modules/products
ng g c core/modules/products/containers/product-view
ng g c core/modules/products/containers/product-edit
ng g c core/modules/products/containers/product-add
ng g c core/modules/products/components/product-form
ng g c core/modules/products/services/product
ng g m core/modules/contact
ng g c core/modules/contact/containers/contact

# Make many more so you get a good feel of how your decisions will impact the project. Make changes, delete the project and run you commands again.

Life cycle hooks

ngOnCh­anges()
Respond when Angular (re)sets data-bound input proper­ties. The method receives a Simple­Changes object of current and previous property values. Called before ngOnInit() and whenever one or more data-bound input properties change.
ngOnInit()
Initialize the direct­ive­/co­mponent after Angular first displays the data-bound properties and sets the direct­ive­/co­mpo­nent's input proper­ties. Called once, after the first ngOnCh­ang­es().
ngDoCh­eck()
Detect and act upon changes that Angular can't or won't detect on its own. Called during every change detection run, immedi­ately after ngOnCh­anges() and ngOnIn­it().
ngAfte­rCo­nte­ntI­nit()
Respond after Angular projects external content into the compon­ent's view / the view that a directive is in. Called once after the first ngDoCh­eck().
ngAfte­rVi­ewI­nit()
Respond after Angular initia­lizes the compon­ent's views and child views / the view that a directive is in. Called once after the first ngAfte­rCo­nte­ntC­hec­ked().
ngAfterViewChecked()
Respond after Angular checks the compon­ent's views and child views / the view that a directive is in. Called after the ngAfte­rVi­ewI­nit() and every subsequent ngAfte­rCo­nte­ntC­hec­ked().
ngOnDe­stroy()
Cleanup just before Angular destroys the direct­ive­/co­mpo­nent. Unsubs­cribe Observ­ables and detach event handlers to avoid memory leaks. Called just before Angular destroys the direct­ive­/co­mpo­nent.