parent
7f58488185
commit
199bf26b0f
@ -458,7 +458,7 @@ figure
|
||||
* dependency injection is wired into the framework and used everywhere.<br><br>
|
||||
* the `Injector` is the main mechanism.
|
||||
* an injector maintains a *container* of service instances that it created.
|
||||
* an injector can create a new service instance from a *provider*.
|
||||
* an injector can create a new service instance using a *provider*.
|
||||
* a *provider* is a recipe for creating a service.
|
||||
|
||||
* we register *providers* with injectors.
|
||||
|
@ -355,24 +355,26 @@
|
||||
<a id="L"></a>
|
||||
:marked
|
||||
## Lifecycle Hooks
|
||||
[Directives](#directive) and [Components](#component) have a lifecycle
|
||||
managed by Angular as it creates, updates and destroys them.
|
||||
|
||||
Developers can tap into key moments in that lifecycle by implementing
|
||||
one or more of the "Lifecycle Hook" interfaces.
|
||||
|
||||
Each interface has a single hook method whose name is the interface name prefixed with `ng`.
|
||||
For example, the `OnInit` interface has a hook method names `ngOnInit`.
|
||||
|
||||
Angular calls these hook methods in the following order:
|
||||
* `ngOnChanges` - called when an [input](#input)/[output](#output) binding values change
|
||||
* `ngOnInit` - after the first `ngOnChanges`
|
||||
* `ngDoCheck` - developer's custom change detection
|
||||
* `ngAfterContentInit` - after component content initialized
|
||||
* `ngAfterContentChecked` - after every check of component content
|
||||
* `ngAfterViewInit` - after component's view(s) are initialized
|
||||
* `ngAfterViewChecked` - after every check of a component's view(s)
|
||||
* `ngOnDestroy` - just before the directive is destroyed.
|
||||
.l-sub-section
|
||||
:marked
|
||||
[Directives](#directive) and [Components](#component) have a lifecycle
|
||||
managed by Angular as it creates, updates and destroys them.
|
||||
|
||||
Developers can tap into key moments in that lifecycle by implementing
|
||||
one or more of the "Lifecycle Hook" interfaces.
|
||||
|
||||
Each interface has a single hook method whose name is the interface name prefixed with `ng`.
|
||||
For example, the `OnInit` interface has a hook method names `ngOnInit`.
|
||||
|
||||
Angular calls these hook methods in the following order:
|
||||
* `ngOnChanges` - called when an [input](#input)/[output](#output) binding values change
|
||||
* `ngOnInit` - after the first `ngOnChanges`
|
||||
* `ngDoCheck` - developer's custom change detection
|
||||
* `ngAfterContentInit` - after component content initialized
|
||||
* `ngAfterContentChecked` - after every check of component content
|
||||
* `ngAfterViewInit` - after component's view(s) are initialized
|
||||
* `ngAfterViewChecked` - after every check of a component's view(s)
|
||||
* `ngOnDestroy` - just before the directive is destroyed.
|
||||
|
||||
.l-main-section
|
||||
<a id="M"></a>
|
||||
@ -382,20 +384,32 @@
|
||||
:marked
|
||||
Angular apps are modular.
|
||||
|
||||
In general we assemble our application from many modules both the ones we write ourselves
|
||||
In general, we assemble our application from many modules, both the ones we write ourselves
|
||||
and the ones we acquire from others.
|
||||
|
||||
A typical module is a cohesive block of code dedicated to a single purpose.
|
||||
|
||||
A module exports something of value in that code, typically one thing such as a class.
|
||||
A module **exports** something of value in that code, typically one thing such as a class.
|
||||
A module that needs that thing, **imports** it.
|
||||
|
||||
The structure of Angular modules and the import/export syntax
|
||||
is based on the [ES2015](#es2015) module standard
|
||||
described [here](http://www.2ality.com/2014/09/es6-modules-final.html).
|
||||
|
||||
An application that adheres to this standard requires a module loader to
|
||||
load modules on request and resolve inter-module dependencies.
|
||||
Angular does not ship with a module loader and does not have a preference
|
||||
for any particular 3rd party library (although most samples use SystemJS).
|
||||
Application developers may pick any module library that conforms to the standard
|
||||
|
||||
Modules are typically named after the file in which the exported thing is defined.
|
||||
|
||||
The Angular [DatePipe](https://github.com/angular/angular/blob/master/modules/angular2/src/common/pipes/date_pipe.ts)
|
||||
class belongs to a module named `date_pipe` in the file `date_pipe.ts`.
|
||||
class belongs to a feature module named `date_pipe` in the file `date_pipe.ts`.
|
||||
|
||||
In general, Angular feature modules such as the `data_pipe` are not exposed directly.
|
||||
Rather they are grouped together with logically related modules in public-facing **library modules**
|
||||
called [**barrels**](#barrel).
|
||||
Developers rarely access Angular feature modules directly.
|
||||
We usually import them from public-facing **library modules**
|
||||
called [**barrels**](#barrel). Barrels are groups of logically related modules.
|
||||
The `angular2/core` barrel is a good example.
|
||||
|
||||
Learn more in "[Modules, barrels and bundles](https://github.com/angular/angular/blob/master/modules/angular2/docs/bundles/overview.md)".
|
||||
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Loading…
x
Reference in New Issue
Block a user