cargdev/angular
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

repackaging: all the file moves

Browse Source
This commit is contained in:
Igor Minar
2016-04-28 08:02:15 -07:00
committed by Misko Hevery
parent 4fe0f1fa65
commit 505da6c0a8
739 changed files with 0 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
modules/@angular/docs/bundles/overview.md Normal file
View File

@ -0,0 +1,92 @@
# TL;DR;
* If you write ES5 use _one_ of the `UMD` bundles.
* If you experiment with Angular2 using online prototyping tools like [plnkr](http://plnkr.co/) or similar use `System.register` bundles with SystemJS loader.
* If you use build tools like Browserify or WebPack - bundle Angular2 as part of your build.
* For all the above cases you must use `angular2-polyfills.js` in a `script` tag to easily include polyfills and external dependencies.
# Modules, barrels and bundles
Angular2 source code is authored using the ES2015 standardized module format where one module corresponds to exactly one file. Multiple modules (files) can be logically grouped into so-called "barrels".
A bundle is a file that contains all the code for one or more barrels.
Most bundles come in several flavors:
* regular and minified (got `.min` in their name);
* regular and "development" (have `.dev` in their name) - "development" bundles contain in-line source maps and don't have minified flavor (minification removes in-lined source maps).
# Bundles, their content and usage scenarios
Angular 2 distributes several types of bundles targeted at specific usages:
* users writing ES5 code without any transpilation steps
* users experimenting with Angular 2 and TypeScript/ES2015 using online tools like plunker, jsbin or similar
Since each identified scenario has slightly different requirements and constraints there are specific bundles for each use-case.
## ES5 and ngUpgrade users
ES5 users and AngularJS 1.x users interested in the `ngUpgrade` path can take advantage of the bundles in the [UMD format](https://github.com/umdjs/umd).
Those are coarse-grained bundles that combine many barrels in one final file.
filename | list of barrels | dev/prod | minified?
------------|-------------------|----------|-------------|--------------|-------------
`angular2-all.umd.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/http`, `angular2/router`, `angular2/instrumentation`, `angular2/upgrade`| prod | no
`angular2-all.umd.min.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/http`, `angular2/router`, `angular2/instrumentation`, `angular2/upgrade` | prod | yes
`angular2-all.umd.dev.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/http`, `angular2/router`, `angular2/instrumentation`, `angular2/upgrade` | dev | no
`angular2-all-testing.umd.dev.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/http`, `angular2/router`, `angular2/instrumentation`, `angular2/upgrade`, `angular2/testing`, `angular2/http/testing`, `angular2/router/testing`, `angular2/platform/testing/browser` | dev | no
**Warning**: bundles in the `UMD` format are _not_ "additive". A single application should use only one bundle from the above list.
## SystemJS loader users
[SystemJS loader](https://github.com/systemjs/systemjs) with on-the-fly (in a browser) transpilations support is very useful for quick experiments using tools like plunker, jsbin or similar.
For this scenario Angular 2 is distributed with bundles in the [System.register format](https://github.com/ModuleLoader/es6-module-loader/wiki/System.register-Explained):
filename | list of barrels | dev/prod | minified?
------------|-------------------|----------|-------------|--------------|-------------
`angular2.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/instrumentation`| prod | no
`angular2.min.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/instrumentation`| prod | yes
`angular2.dev.js` | `angular2/core`, `angular2/common`, `angular2/compiler`, `angular2/platform/browser`, `angular2/platform/common_dom`, `angular2/instrumentation`| dev | no
`http.js` | `angular2/http` | prod | no
`http.min.js` | `angular2/http` | prod | yes
`http.dev.js` | `angular2/http` | dev | no
`router.js` | `angular2/router` | prod | no
`router.min.js` | `angular2/router` | prod | yes
`router.dev.js` | `angular2/router` | dev | no
`upgrade.js` | `angular2/upgrade` | prod | no
`upgrade.min.js` | `angular2/upgrade` | prod | yes
`upgrade.dev.js` | `angular2/upgrade` | dev | no
`testing.dev.js` | `angular2/testing`, `angular2/http/testing`, `angular2/router/testing`, `angular2/platform/testing/browser` | dev | no
**Note**: bundles in the `System.register` format are "additive" - it is quite common to include several bundles in one application.
For example people using Angular 2 with `http` and `router` would include: `angular2.js`, `http.js` and `router.js`.
## Browserify / JSPM / Rollup / WebPack users
Angular 2 doesn't provide any bundles for use with packaging tools Browserify or WebPack. Those tools are sophisticated enough to build optimal bundles for production use from individual Angular 2 files distributed in the npm package.
An example of an Angular 2 project built with WebPack can be found in the [angular2-seed](https://github.com/angular/angular2-seed) repository.
# Polyfills and external dependencies
## Required Polyfills
Polyfills are required for Angular 2 to function properly (the exact list depends on the browser used) and external dependencies ([zone.js](https://github.com/angular/zone.js)).
To ease setup of Angular 2 applications there is one file - `angular2-polyfills.js` - that combines:
* a polyfill mandatory for all browsers: [reflect-metadata](https://www.npmjs.com/package/reflect-metadata)
* [zone.js](https://github.com/angular/zone.js)
**Note**: `angular2-polyfills.js` contains code that should be loaded into the browser as the very first code of the web application even before the module loader. The preferred solution is to load the mentioned file in a `script` tag as early as possible.
## RxJS
[RxJS](https://github.com/ReactiveX/RxJS) is a required dependency of Angular 2.
You should include RxJS in your project by declaring a dependency on the [`rxjs` npm package](https://www.npmjs.com/package/rxjs).
Depending on if you are using Angular bundles or not you can either use RxJS bundles from `node_modules/rxjs/bundles/` or configure your bundler to pull in the individual files from the npm package.
## ES6 shims (optional)
Users of pre-ES6 browsers might need to add an ES6 shim (e.g. [es6-shim](https://github.com/paulmillr/es6-shim))

10
modules/@angular/docs/change_detection/change_detection.md Normal file
View File

@ -0,0 +1,10 @@
@name Change Detection
@description
# Change Detection
* Mechanisms by which changes are detected in the model
* DAG
* Order of evaluation
* Pure Functions
* `onChange` method
* Parser

7
modules/@angular/docs/change_detection/expressions.md Normal file
View File

@ -0,0 +1,7 @@
# Expressions
## Binding Semantics
### Formatters
## Statement Semantics

3
modules/@angular/docs/change_detection/record.md Normal file
View File

@ -0,0 +1,3 @@
# Record
## RecordRange

18
modules/@angular/docs/cheatsheet/bootstrapping.md Normal file
View File

@ -0,0 +1,18 @@
@cheatsheetSection
Bootstrapping
@cheatsheetIndex 0
@description
{@target ts}`import {bootstrap} from 'angular2/platform/browser';`{@endtarget}
{@target js}Available from the `ng.platform.browser` namespace{@endtarget}
{@target dart}`import 'package:angular2/platform/browser.dart';`{@endtarget}
@cheatsheetItem
syntax(ts dart):
`bootstrap​(MyAppComponent, [MyService, provide(...)]);`|`provide`
syntax(js):
`document.addEventListener('DOMContentLoaded', function () {
ng.platform.browser.bootstrap(MyAppComponent,
[MyService, ng.core.provide(...)]);
});`|`provide`
description:
Bootstraps an application with MyAppComponent as the root component and configures the DI providers. {@target js}Must be wrapped in the event listener to fire when the page loads.{@endtarget}

35
modules/@angular/docs/cheatsheet/built-in-directives.md Normal file
View File

@ -0,0 +1,35 @@
@cheatsheetSection
Built-in directives
@cheatsheetIndex 2
@description
{@target ts}`import {NgIf, ...} from 'angular2/common';`{@endtarget}
{@target js}Available from the `ng.common` namespace{@endtarget}
{@target dart}Available using `platform_directives` in pubspec{@endtarget}
@cheatsheetItem
syntax:
`<section *ngIf="showSection">`|`*ngIf`
description:
Removes or recreates a portion of the DOM tree based on the showSection expression.
@cheatsheetItem
syntax:
`<li *ngFor="let item of list">`|`*ngFor`
description:
Turns the li element and its contents into a template, and uses that to instantiate a view for each item in list.
@cheatsheetItem
syntax:
`<div [ngSwitch]="conditionExpression">
<template [ngSwitchWhen]="case1Exp">...</template>
<template ngSwitchWhen="case2LiteralString">...</template>
<template ngSwitchDefault>...</template>
</div>`|`[ngSwitch]`|`[ngSwitchWhen]`|`ngSwitchWhen`|`ngSwitchDefault`
description:
Conditionally swaps the contents of the div by selecting one of the embedded templates based on the current value of conditionExpression.
@cheatsheetItem
syntax:
`<div [ngClass]="{active: isActive, disabled: isDisabled}">`|`[ngClass]`
description:
Binds the presence of CSS classes on the element to the truthiness of the associated map values. The right-hand side expression should return {class-name: true/false} map.

60
modules/@angular/docs/cheatsheet/class-decorators.md Normal file
View File

@ -0,0 +1,60 @@
@cheatsheetSection
Class decorators
@cheatsheetIndex 4
@description
{@target ts}`import {Directive, ...} from 'angular2/core';`{@endtarget}
{@target js}Available from the `ng.core` namespace{@endtarget}
{@target dart}`import 'package:angular2/core.dart';`{@endtarget}
@cheatsheetItem
syntax(ts):
`@Component({...})
class MyComponent() {}`|`@Component({...})`
syntax(js):
`var MyComponent = ng.core.Component({...}).Class({...})`|`ng.core.Component({...})`
syntax(dart):
`@Component(...)
class MyComponent() {}`|`@Component(...)`
description:
Declares that a class is a component and provides metadata about the component.
@cheatsheetItem
syntax(ts):
`@Directive({...})
class MyDirective() {}`|`@Directive({...})`
syntax(js):
`var MyDirective = ng.core.Directive({...}).Class({...})`|`ng.core.Directive({...})`
syntax(dart):
`@Directive(...)
class MyDirective() {}`|`@Directive(...)`
description:
Declares that a class is a directive and provides metadata about the directive.
@cheatsheetItem
syntax(ts):
`@Pipe({...})
class MyPipe() {}`|`@Pipe({...})`
syntax(js):
`var MyPipe = ng.core.Pipe({...}).Class({...})`|`ng.core.Pipe({...})`
syntax(dart):
`@Pipe(...)
class MyPipe() {}`|`@Pipe(...)`
description:
Declares that a class is a pipe and provides metadata about the pipe.
@cheatsheetItem
syntax(ts):
`@Injectable()
class MyService() {}`|`@Injectable()`
syntax(js):
`var OtherService = ng.core.Class({constructor: function() { }});
var MyService = ng.core.Class({constructor: [OtherService, function(otherService) { }]});`|`var MyService = ng.core.Class({constructor: [OtherService, function(otherService) { }]});`
syntax(dart):
`@Injectable()
class MyService() {}`|`@Injectable()`
description:
{@target ts dart}Declares that a class has dependencies that should be injected into the constructor when the dependency injector is creating an instance of this class.
{@endtarget}
{@target js}
Declares a service to inject into a class by providing an array with the services with the final item being the function which will receive the injected services.
{@endtarget}

46
modules/@angular/docs/cheatsheet/component-configuration.md Normal file
View File

@ -0,0 +1,46 @@
@cheatsheetSection
Component configuration
@cheatsheetIndex 6
@description
{@target js}`ng.core.Component` extends `ng.core.Directive`,
so the `ng.core.Directive` configuration applies to components as well{@endtarget}
{@target ts dart}`@Component` extends `@Directive`,
so the `@Directive` configuration applies to components as well{@endtarget}
@cheatsheetItem
syntax(ts dart):
`viewProviders: [MyService, provide(...)]`|`viewProviders:`
syntax(js):
`viewProviders: [MyService, ng.core.provide(...)]`|`viewProviders:`
description:
Array of dependency injection providers scoped to this component's view.
@cheatsheetItem
syntax:
`template: 'Hello {{name}}'
templateUrl: 'my-component.html'`|`template:`|`templateUrl:`
description:
Inline template / external template URL of the component's view.
@cheatsheetItem
syntax:
`styles: ['.primary {color: red}']
styleUrls: ['my-component.css']`|`styles:`|`styleUrls:`
description:
List of inline CSS styles / external stylesheet URLs for styling component’s view.
@cheatsheetItem
syntax:
`directives: [MyDirective, MyComponent]`|`directives:`
description:
List of directives used in the the component’s template.
@cheatsheetItem
syntax:
`pipes: [MyPipe, OtherPipe]`|`pipes:`
description:
List of pipes used in the component's template.

33
modules/@angular/docs/cheatsheet/dependency-injection.md Normal file
View File

@ -0,0 +1,33 @@
@cheatsheetSection
Dependency injection configuration
@cheatsheetIndex 9
@description
{@target ts}`import {provide} from 'angular2/core';`{@endtarget}
{@target js}Available from the `ng.core` namespace{@endtarget}
{@target dart}`import 'package:angular2/core.dart';`{@endtarget}
@cheatsheetItem
syntax(ts dart):
`provide(MyService, {useClass: MyMockService})`|`provide`|`useClass`
syntax(js):
`ng.core.provide(MyService, {useClass: MyMockService})`|`provide`|`useClass`
description:
Sets or overrides the provider for MyService to the MyMockService class.
@cheatsheetItem
syntax(ts dart):
`provide(MyService, {useFactory: myFactory})`|`provide`|`useFactory`
syntax(js):
`ng.core.provide(MyService, {useFactory: myFactory})`|`provide`|`useFactory`
description:
Sets or overrides the provider for MyService to the myFactory factory function.
@cheatsheetItem
syntax(ts dart):
`provide(MyValue, {useValue: 41})`|`provide`|`useValue`
syntax(js):
`provide(MyValue, {useValue: 41})`|`provide`|`useValue`
description:
Sets or overrides the provider for MyValue to the value 41.

80
modules/@angular/docs/cheatsheet/directive-and-component-decorators.md Normal file
View File

@ -0,0 +1,80 @@
@cheatsheetSection
Class field decorators for directives and components
@cheatsheetIndex 7
@description
{@target ts}`import {Input, ...} from 'angular2/core';`{@endtarget}
{@target js}Available from the `ng.core` namespace{@endtarget}
{@target dart}`import 'package:angular2/core.dart';`{@endtarget}
@cheatsheetItem
syntax(ts dart):
`@Input() myProperty;`|`@Input()`
syntax(js):
`ng.core.Input(myProperty, myComponent);`|`ng.core.Input(`|`);`
description:
Declares an input property that we can update via property binding (e.g.
`<my-cmp [my-property]="someExpression">`).
@cheatsheetItem
syntax(ts dart):
`@Output() myEvent = new EventEmitter();`|`@Output()`
syntax(js):
`myEvent = new ng.core.EventEmitter(); ng.core.Output(myEvent, myComponent);`|`ng.core.Output(`|`);`
description:
Declares an output property that fires events to which we can subscribe with an event binding (e.g. `<my-cmp (my-event)="doSomething()">`).
@cheatsheetItem
syntax(ts dart):
`@HostBinding('[class.valid]') isValid;`|`@HostBinding('[class.valid]')`
syntax(js):
`ng.core.HostBinding('[class.valid]', 'isValid', myComponent);`|`ng.core.HostBinding('[class.valid]', 'isValid'`|`);`
description:
Binds a host element property (e.g. CSS class valid) to directive/component property (e.g. isValid).
@cheatsheetItem
syntax(ts dart):
`@HostListener('click', ['$event']) onClick(e) {...}`|`@HostListener('click', ['$event'])`
syntax(js):
`ng.core.HostListener('click', ['$event'], onClick(e) {...}, myComponent);`|`ng.core.HostListener('click', ['$event'], onClick(e)`|`);`
description:
Subscribes to a host element event (e.g. click) with a directive/component method (e.g. onClick), optionally passing an argument ($event).
@cheatsheetItem
syntax(ts dart):
`@ContentChild(myPredicate) myChildComponent;`|`@ContentChild(myPredicate)`
syntax(js):
`ng.core.ContentChild(myPredicate, 'myChildComponent', myComponent);`|`ng.core.ContentChild(myPredicate,`|`);`
description:
Binds the first result of the component content query (myPredicate) to the myChildComponent property of the class.
@cheatsheetItem
syntax(ts dart):
`@ContentChildren(myPredicate) myChildComponents;`|`@ContentChildren(myPredicate)`
syntax(js):
`ng.core.ContentChildren(myPredicate, 'myChildComponents', myComponent);`|`ng.core.ContentChildren(myPredicate,`|`);`
description:
Binds the results of the component content query (myPredicate) to the myChildComponents property of the class.
@cheatsheetItem
syntax(ts dart):
`@ViewChild(myPredicate) myChildComponent;`|`@ViewChild(myPredicate)`
syntax(js):
`ng.core.ViewChild(myPredicate, 'myChildComponent', myComponent);`|`ng.core.ViewChild(myPredicate,`|`);`
description:
Binds the first result of the component view query (myPredicate) to the myChildComponent property of the class. Not available for directives.
@cheatsheetItem
syntax(ts dart):
`@ViewChildren(myPredicate) myChildComponents;`|`@ViewChildren(myPredicate)`
syntax(js):
`ng.core.ViewChildren(myPredicate, 'myChildComponents', myComponent);`|`ng.core.ViewChildren(myPredicate,`|`);`
description:
Binds the results of the component view query (myPredicate) to the myChildComponents property of the class. Not available for directives.

24
modules/@angular/docs/cheatsheet/directive-configuration.md Normal file
View File

@ -0,0 +1,24 @@
@cheatsheetSection
Directive configuration
@cheatsheetIndex 5
@description
{@target ts}`@Directive({ property1: value1, ... })`{@endtarget}
{@target js}`ng.core.Directive({ property1: value1, ... }).Class({...})`{@endtarget}
{@target dart}`@Directive(property1: value1, ...)`{@endtarget}
@cheatsheetItem
syntax:
`selector: '.cool-button:not(a)'`|`selector:`
description:
Specifies a CSS selector that identifies this directive within a template. Supported selectors include `element`,
`[attribute]`, `.class`, and `:not()`.
Does not support parent-child relationship selectors.
@cheatsheetItem
syntax(ts dart):
`providers: [MyService, provide(...)]`|`providers:`
syntax(js):
`providers: [MyService, ng.core.provide(...)]`|`providers:`
description:
Array of dependency injection providers for this directive and its children.

13
modules/@angular/docs/cheatsheet/forms.md Normal file
View File

@ -0,0 +1,13 @@
@cheatsheetSection
Forms
@cheatsheetIndex 3
@description
{@target ts}`import {FORM_DIRECTIVES} from 'angular2/common';`{@endtarget}
{@target js}Available from `ng.common.FORM_DIRECTIVES`{@endtarget}
{@target dart}Available using `platform_directives` in pubspec{@endtarget}
@cheatsheetItem
syntax:
`<input [(ngModel)]="userName">`|`[(ngModel)]`
description:
Provides two-way data-binding, parsing and validation for form controls.

88
modules/@angular/docs/cheatsheet/lifecycle hooks.md Normal file
View File

@ -0,0 +1,88 @@
@cheatsheetSection
Directive and component change detection and lifecycle hooks
@cheatsheetIndex 8
@description
{@target ts dart}(implemented as class methods){@endtarget}
{@target js}(implemented as component properties){@endtarget}
@cheatsheetItem
syntax(ts):
`constructor(myService: MyService, ...) { ... }`|`constructor(myService: MyService, ...)`
syntax(js):
`constructor: function(MyService, ...) { ... }`|`constructor: function(MyService, ...)`
syntax(dart):
`MyAppComponent(MyService myService, ...) { ... }`|`MyAppComponent(MyService myService, ...)`
description:
The class constructor is called before any other lifecycle hook. Use it to inject dependencies, but avoid any serious work here.
@cheatsheetItem
syntax(ts dart):
`ngOnChanges(changeRecord) { ... }`|`ngOnChanges(changeRecord)`
syntax(js):
`ngOnChanges: function(changeRecord) { ... }`|`ngOnChanges: function(changeRecord)`
description:
Called after every change to input properties and before processing content or child views.
@cheatsheetItem
syntax(ts dart):
`ngOnInit() { ... }`|`ngOnInit()`
syntax(js):
`ngOnInit: function() { ... }`|`ngOnInit: function()`
description:
Called after the constructor, initializing input properties, and the first call to ngOnChanges.
@cheatsheetItem
syntax(ts dart):
`ngDoCheck() { ... }`|`ngDoCheck()`
syntax(js):
`ngDoCheck: function() { ... }`|`ngDoCheck: function()`
description:
Called every time that the input properties of a component or a directive are checked. Use it to extend change detection by performing a custom check.
@cheatsheetItem
syntax(ts dart):
`ngAfterContentInit() { ... }`|`ngAfterContentInit()`
syntax(js):
`ngAfterContentInit: function() { ... }`|`ngAfterContentInit: function()`
description:
Called after ngOnInit when the component's or directive's content has been initialized.
@cheatsheetItem
syntax(ts dart):
`ngAfterContentChecked() { ... }`|`ngAfterContentChecked()`
syntax(js):
`ngAfterContentChecked: function() { ... }`|`ngAfterContentChecked: function()`
description:
Called after every check of the component's or directive's content.
@cheatsheetItem
syntax(ts dart):
`ngAfterViewInit() { ... }`|`ngAfterViewInit()`
syntax(js):
`ngAfterViewInit: function() { ... }`|`ngAfterViewInit: function()`
description:
Called after ngAfterContentInit when the component's view has been initialized. Applies to components only.
@cheatsheetItem
syntax(ts dart):
`ngAfterViewChecked() { ... }`|`ngAfterViewChecked()`
syntax(js):
`ngAfterViewChecked: function() { ... }`|`ngAfterViewChecked: function()`
description:
Called after every check of the component's view. Applies to components only.
@cheatsheetItem
syntax(ts dart):
`ngOnDestroy() { ... }`|`ngOnDestroy()`
syntax(js):
`ngOnDestroy: function() { ... }`|`ngOnDestroy: function()`
description:
Called once, before the instance is destroyed.

101
modules/@angular/docs/cheatsheet/routing.md Normal file
View File

@ -0,0 +1,101 @@
@cheatsheetSection
Routing and navigation
@cheatsheetIndex 10
@description
{@target ts}`import {RouteConfig, ROUTER_DIRECTIVES, ROUTER_PROVIDERS, ...} from 'angular2/router';`{@endtarget}
{@target js}Available from the `ng.router` namespace{@endtarget}
{@target dart}`import 'package:angular2/router.dart';`{@endtarget}
@cheatsheetItem
syntax(ts):
`@RouteConfig([
{ path: '/:myParam', component: MyComponent, name: 'MyCmp' },
{ path: '/staticPath', component: ..., name: ...},
{ path: '/*wildCardParam', component: ..., name: ...}
])
class MyComponent() {}`|`@RouteConfig`
syntax(js):
`var MyComponent = ng.router.RouteConfig([
{ path: '/:myParam', component: MyComponent, name: 'MyCmp' },
{ path: '/staticPath', component: ..., name: ...},
{ path: '/*wildCardParam', component: ..., name: ...}
]).Class({
constructor: function() {}
});`|`ng.router.RouteConfig`
syntax(dart):
`@RouteConfig(const [
const Route(path: '/:myParam', component: MyComponent, name: 'MyCmp' ),
])`|`@RouteConfig`
description:
Configures routes for the decorated component. Supports static, parameterized, and wildcard routes.
@cheatsheetItem
syntax:
`<router-outlet></router-outlet>`|`router-outlet`
description:
Marks the location to load the component of the active route.
@cheatsheetItem
syntax:
`<a [routerLink]="[ '/MyCmp', {myParam: 'value' } ]">`|`[routerLink]`
description:
Creates a link to a different view based on a route instruction consisting of a route name and optional parameters. The route name matches the as property of a configured route. Add the '/' prefix to navigate to a root route; add the './' prefix for a child route.
@cheatsheetItem
syntax(ts):
`@CanActivate(() => { ... })class MyComponent() {}`|`@CanActivate`
syntax(js):
`var MyComponent = ng.router.CanActivate(function() { ... }).Component({...}).Class({constructor: ...});`|`ng.router.CanActivate(function() { ... })`
syntax(dart):
`@CanActivate(() => ...)class MyComponent() {}`|`@CanActivate`
description:
A component decorator defining a function that the router should call first to determine if it should activate this component. Should return a boolean or a {@target js ts}promise{@endtarget}{@target dart}future{@endtarget}.
@cheatsheetItem
syntax(ts dart):
`routerOnActivate(nextInstruction, prevInstruction) { ... }`|`routerOnActivate`
syntax(js):
`routerOnActivate: function(nextInstruction, prevInstruction) { ... }`|`routerOnActivate`
description:
After navigating to a component, the router calls the component's routerOnActivate method (if defined).
@cheatsheetItem
syntax(ts dart):
`routerCanReuse(nextInstruction, prevInstruction) { ... }`|`routerCanReuse`
syntax(js):
`routerCanReuse: function(nextInstruction, prevInstruction) { ... }`|`routerCanReuse`
description:
The router calls a component's routerCanReuse method (if defined) to determine whether to reuse the instance or destroy it and create a new instance. Should return a boolean or a {@target js ts}promise{@endtarget}{@target dart}future{@endtarget}.
@cheatsheetItem
syntax(ts dart):
`routerOnReuse(nextInstruction, prevInstruction) { ... }`|`routerOnReuse`
syntax(js):
`routerOnReuse: function(nextInstruction, prevInstruction) { ... }`|`routerOnReuse`
description:
The router calls the component's routerOnReuse method (if defined) when it re-uses a component instance.
@cheatsheetItem
syntax(ts dart):
`routerCanDeactivate(nextInstruction, prevInstruction) { ... }`|`routerCanDeactivate`
syntax(js):
`routerCanDeactivate: function(nextInstruction, prevInstruction) { ... }`|`routerCanDeactivate`
description:
The router calls the routerCanDeactivate methods (if defined) of every component that would be removed after a navigation. The navigation proceeds if and only if all such methods return true or a {@target js ts}promise that is resolved{@endtarget}{@target dart}future that completes successfully{@endtarget}.
@cheatsheetItem
syntax(ts dart):
`routerOnDeactivate(nextInstruction, prevInstruction) { ... }`|`routerOnDeactivate`
syntax(js):
`routerOnDeactivate: function(nextInstruction, prevInstruction) { ... }`|`routerOnDeactivate`
description:
Called before the directive is removed as the result of a route change. May return a {@target js ts}promise{@endtarget}{@target dart}future{@endtarget} that pauses removing the directive until the {@target js ts}promise resolves{@endtarget}{@target dart}future completes{@endtarget}.

80
modules/@angular/docs/cheatsheet/template-syntax.md Normal file
View File

@ -0,0 +1,80 @@
@cheatsheetSection
Template syntax
@cheatsheetIndex 1
@description
@cheatsheetItem
syntax:
`<input [value]="firstName">`|`[value]`
description:
Binds property `value` to the result of expression `firstName`.
@cheatsheetItem
syntax:
`<div [attr.role]="myAriaRole">`|`[attr.role]`
description:
Binds attribute `role` to the result of expression `myAriaRole`.
@cheatsheetItem
syntax:
`<div [class.extra-sparkle]="isDelightful">`|`[class.extra-sparkle]`
description:
Binds the presence of the CSS class `extra-sparkle` on the element to the truthiness of the expression `isDelightful`.
@cheatsheetItem
syntax:
`<div [style.width.px]="mySize">`|`[style.width.px]`
description:
Binds style property `width` to the result of expression `mySize` in pixels. Units are optional.
@cheatsheetItem
syntax:
`<button (click)="readRainbow($event)">`|`(click)`
description:
Calls method `readRainbow` when a click event is triggered on this button element (or its children) and passes in the event object.
@cheatsheetItem
syntax:
`<div title="Hello {{ponyName}}">`|`{{ponyName}}`
description:
Binds a property to an interpolated string, e.g. "Hello Seabiscuit". Equivalent to:
`<div [title]="'Hello' + ponyName">`
@cheatsheetItem
syntax:
`<p>Hello {{ponyName}}</p>`|`{{ponyName}}`
description:
Binds text content to an interpolated string, e.g. "Hello Seabiscuit".
@cheatsheetItem
syntax:
`<my-cmp [(title)]="name">`|`[(title)]`
description:
Sets up two-way data binding. Equivalent to: `<my-cmp [title]="name" (titleChange)="name=$event">`
@cheatsheetItem
syntax:
`<video #movieplayer ...>
<button (click)="movieplayer.play()">
</video>`|`#movieplayer`|`(click)`
description:
Creates a local variable `movieplayer` that provides access to the `video` element instance in data-binding and event-binding expressions in the current template.
@cheatsheetItem
syntax:
`<p *myUnless="myExpression">...</p>`|`*myUnless`
description:
The `*` symbol means that the current element will be turned into an embedded template. Equivalent to:
`<template [myUnless]="myExpression"><p>...</p></template>`
@cheatsheetItem
syntax:
`<p>Card No.: {{cardNumber | myCreditCardNumberFormatter}}</p>`|`{{cardNumber | myCreditCardNumberFormatter}}`
description:
Transforms the current value of expression `cardNumber` via the pipe called `myCreditCardNumberFormatter`.
@cheatsheetItem
syntax:
`<p>Employer: {{employer?.companyName}}</p>`|`{{employer?.companyName}}`
description:
The safe navigation operator (`?`) means that the `employer` field is optional and if `undefined`, the rest of the expression should be ignored.

3
modules/@angular/docs/core/00_index.md Normal file
View File

@ -0,0 +1,3 @@
# Overview
* High level description of all of the components.

610
modules/@angular/docs/core/01_templates.md Normal file
View File

@ -0,0 +1,610 @@
# Templates
Templates are markup which is added to HTML to declaratively describe how the application model should be
projected to DOM as well as which DOM events should invoke which methods on the controller. Templates contain
syntaxes which are core to Angular and allows for data-binding, event-binding, template-instantiation.
The design of the template syntax has these properties:
* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity whether the value should be
interpreted as string literal or as an expression.)
* All events and their statements are easily identifiable.
* All places of DOM instantiation are easily identifiable.
* All places of variable declaration are easily identifiable.
The above properties guarantee that the templates are easy to parse by tools (such as IDEs) and reason about by people.
At no point is it necessary to understand which directives are active or what their semantics are in order to reason
about the template runtime characteristics.
## Summary
Below is a summary of the kinds of syntaxes which Angular templating supports. The syntaxes are explained in more
detail in the following sections.
<table>
<thead>
<tr>
<th>Description</th><th>Short</th><th>Canonical</th>
</tr>
</thead>
<tbody>
<tr>
<th>Text Interpolation</th>
<td>
<pre>
&lt;div&gt;{{exp}}&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div&gt;
Hello {{name}}!
&lt;br&gt;
Goodbye {{name}}!
&lt;/div&gt;
</pre>
</td>
<td>
<pre>
&lt;div [text|index]="exp"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div
[text|0]=" 'Hello' + stringify(name) + '!' "
[text|2]=" 'Goodbye' + stringify(name) + '!' "&gt;
&lt;b&gt;x&lt;/b&gt;
&lt;/div&gt;
</pre>
</td>
</tr>
<tr>
<th>Property Interpolation</th>
<td>
<pre>
&lt;div name="{{exp}}"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div class="{{selected}}"&gt;&lt;/div&gt;
</pre>
</td>
<td>
<pre>
&lt;div [name]="stringify(exp)"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div [title]="stringify(selected)"&gt;&lt;/div&gt;
</pre>
</td>
</tr>
<tr>
<th>Property binding</th>
<td>
<pre>
&lt;div [prop]="exp"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div [hidden]="true"&gt;&lt;/div&gt;
</pre>
</td>
<td>
<pre>
&lt;div bind-prop="exp"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div bind-hidden="true"&gt;&lt;/div&gt;
</pre>
</td>
</tr>
<tr>
<th>Event binding (non-bubbling)</th>
<td>
<pre>
&lt;div (event)="statement"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;div (click)="doX()"&gt;&lt;/div&gt;
</pre>
</td>
<td>
<pre>
&lt;div on-event="statement"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;video #player&gt;
&lt;button (click)="player.play()"&gt;play&lt;/button&gt;
&lt;/video&gt;
</pre>
Or:
<pre>
&lt;div def="symbol"&gt;&lt;/div&gt;
</pre>
Example:
<pre>
&lt;video def="player"&gt;
&lt;button on-click="player.play()"&gt;play&lt;/button&gt;
&lt;/video&gt;
</pre>
</td>
</tr>
<tr>
<th>Inline Template</th>
<td>
<pre>
&lt;div template="..."&gt;...&lt;/div&gt;
</pre>
Example:
<pre>
&lt;ul&gt;
&lt;li template="for: #item of items"&gt;
{{item}}
&lt;/li&gt;
&lt;/ul&gt;
</pre>
</td>
<td>
<pre>
&lt;template&gt;...&lt;/template&gt;
</pre>
Example:
<pre>
&lt;ul&gt;
&lt;template def-for:"item"
bind-for-in="items"&gt;
&lt;li&gt;
{{item}}
&lt;/li&gt;
&lt;/template&gt;
&lt;/ul&gt;
</pre>
</td>
</tr>
<tr>
<th>Explicit Template</th>
<td>
<pre>
&lt;template&gt;...&lt;/template&gt;
</pre>
Example:
<pre>
&lt;template #for="item"
[for-in]="items"&gt;
_some_content_to_repeat_
&lt;/template&gt;
</pre>
</td>
<td>
<pre>
&lt;template&gt;...&lt;/template&gt;
</pre>
Example:
<pre>
&lt;template def-for="item"
bind-for-in="items"&gt;
_some_content_to_repeat_
&lt;/template&gt;
</pre>
</td>
</tr>
</tbody>
</table>
## Property Binding
Binding application model data to the UI is the most common kind of bindings in an Angular application. The bindings
are always in the form of `property-name` which is assigned an `expression`. The generic form is:
<table>
<tr>
<th>Short form</th>
<td><pre>&lt;some-element [some-property]="expression"&gt;</pre></td>
</tr>
<tr>
<th>Canonical form</th>
<td><pre>&lt;some-element bind-some-property="expression"&gt;</pre></td>
</tr>
</table>
Where:
* `some-element` can be any existing DOM element.
* `some-property` (escaped with `[]` or `bind-`) is the name of the property on `some-element`. In this case the
dash-case is converted into camel-case `someProperty`.
* `expression` is a valid expression (as defined in section below).
Example:
```
<div [title]="user.firstName">
```
In the above example the `title` property of the `div` element will be updated whenever the `user.firstName` changes
its value.
Key points:
* The binding is to the element property not the element attribute.
* To prevent custom element from accidentally reading the literal `expression` on the title element, the attribute name
is escaped. In our case the `title` is escaped to `[title]` through the addition of square brackets `[]`.
* A binding value (in this case `user.firstName`) will always be an expression, never a string literal.
NOTE: Unlike Angular v1, Angular v2 binds to properties of elements rather than attributes of elements. This is
done to better support custom elements, and to allow binding for values other than strings.
NOTE: Some editors/server side pre-processors may have trouble generating `[]` around the attribute name. For this
reason Angular also supports a canonical version which is prefixed using `bind-`.
### String Interpolation
Property bindings are the only data bindings which Angular supports, but for convenience Angular supports an interpolation
syntax which is just a short hand for the data binding syntax.
```
<span>Hello {{name}}!</span>
```
is a short hand for:
```
<span [text|0]=" 'Hello ' + stringify(name) + '!' "></span>
```
The above says to bind the `'Hello ' + stringify(name) + '!'` expression to the zero-th child of the `span`'s `text`
property. The index is necessary in case there are more than one text nodes, or if the text node we wish to bind to
is not the first one.
Similarly the same rules apply to interpolation inside attributes.
```
<span title="Hello {{name}}!"></span>
```
is a short hand for:
```
<span [title]=" 'Hello ' + stringify(name) + '!' "></span>
```
NOTE: `stringify()` is a built in implicit function which converts its argument to a string representation, while
keeping `null` and `undefined` as empty strings.
## Local Variables
## Inline Templates
Data binding allows updating the DOM's properties, but it does not allow for changing of the DOM structure. To change
DOM structure we need the ability to define child templates, and then instantiate these templates into Views. The
Views than can be inserted and removed as needed to change the DOM structure.
<table>
<tr>
<th>Short form</th>
<td>
<pre>
parent template
&lt;element&gt;
&lt;some-element template="instantiating-directive-microsyntax"&gt;child template&lt;/some-element&gt;
&lt;/element&gt;
</pre>
</td>
</tr>
<tr>
<th>Canonical form</th>
<td>
<pre>
parent template
&lt;element&gt;
&lt;template instantiating-directive-bindings&gt;
&lt;some-element&gt;child template&lt;/some-element&gt;
&lt;/template&gt;
&lt;/element&gt;
</pre>
</td>
</tr>
</table>
Where:
* `template` defines a child template and designates the anchor where Views (instances of the template) will be
inserted. The template can be defined implicitly with `template` attribute, which turns the current element into
a template, or explicitly with `<template>` element. Explicit declaration is longer, but it allows for having
templates which have more than one root DOM node.
* `viewport` is required for templates. The directive is responsible for deciding when
and in which order should child views be inserted into this location. Such a directive usually has one or
more bindings and can be represented as either `viewport-directive-bindings` or
`viewport-directive-microsyntax` on `template` element or attribute. See template microsyntax for more details.
Example of conditionally included template:
```
Hello {{user}}!
<div template="ngIf: isAdministrator">
...administrator menu here...
</div>
```
In the above example the `ngIf` directive determines whether the child view (an instance of the child template) should be
inserted into the root view. The `ngIf` makes this decision based on if the `isAdministrator` binding is true.
The above example is in the short form, for better clarity let's rewrite it in the canonical form, which is functionally
identical.
```
Hello {{user}}!
<template [ngIf]="isAdministrator">
<div>
...administrator menu here...
</div>
</template>
```
### Template Microsyntax
Often times it is necessary to encode a lot of different bindings into a template to control how the instantiation
of the templates occurs. One such example is `ngFor`.
```
<form #foo=form>
</form>
<ul>
<template [ngFor] #person [ngForOf]="people" #i="index">
<li>{{i}}. {{person}}<li>
</template>
</ul>
```
Where:
* `[ngFor]` triggers the for directive.
* `#person` exports the implicit `ngFor` item.
* `[ngForOf]="people"` binds an iterable object to the `ngFor` controller.
* `#i=index` exports item index as `i`.
The above example is explicit but quite wordy. For this reason in most situations a short hand version of the
syntax is preferable.
```
<ul>
<li template="ngFor; #person; of=people; #i=index;">{{i}}. {{person}}<li>
</ul>
```
Notice how each key value pair is translated to a `key=value;` statement in the `template` attribute. This makes the
repeat syntax a much shorter, but we can do better. Turns out that most punctuation is optional in the short version
which allows us to further shorten the text.
```
<ul>
<li template="ngFor #person of people #i=index">{{i}}. {{person}}<li>
</ul>
```
We can also optionally use `var` instead of `#` and add `:` to `for` which creates the following recommended
microsyntax for `ngFor`.
```
<ul>
<li template="ngFor: var person of people; var i=index">{{i}}. {{person}}<li>
</ul>
```
Finally, we can move the `ngFor` keyword to the left hand side and prefix it with `*` as so:
```
<ul>
<li *ngFor="let person of people; var i=index">{{i}}. {{person}}<li>
</ul>
```
The format is intentionally defined freely, so that developers of directives can build an expressive microsyntax for
their directives. The following code describes a more formal definition.
```
expression: ... // as defined in Expressions section
local: [a-zA-Z][a-zA-Z0-9]* // exported variable name available for binding
internal: [a-zA-Z][a-zA-Z0-9]* // internal variable name which the directive exports.
key: [a-z][-|_|a-z0-9]]* // key which maps to attribute name
keyExpression: key[:|=]?expression // binding which maps an expression to a property
varExport: [#|var]local(=internal)? // binding which exports a local variable from a directive
microsyntax: ([[key|keyExpression|varExport][;|,]?)*
```
Where
* `expression` is an Angular expression as defined in section: Expressions.
* `local` is a local identifier for local variables.
* `internal` is an internal variable which the directive exports for binding.
* `key` is an attribute name usually only used to trigger a specific directive.
* `keyExpression` is a property name to which the expression will be bound to.
* `varExport` allows exporting of directive internal state as variables for further binding. If no `internal` name
is specified, the exporting is to an implicit variable.
* `microsyntax` allows you to build a simple microsyntax which can still clearly identify which expressions bind to
which properties as well as which variables are exported for binding.
NOTE: the `template` attribute must be present to make it clear to the user that a sub-template is being created. This
goes along with the philosophy that the developer should be able to reason about the template without understanding the
semantics of the instantiator directive.
## Binding Events
Binding events allows wiring events from DOM (or other components) to the Angular controller.
<table>
<tr>
<th>Short form</th>
<td><pre>&lt;some-element (some-event)="statement"&gt;</pre></td>
</tr>
<tr>
<th>Canonical form</th>
<td><pre>&lt;some-element on-some-event="statement"&gt;</pre></td>
</tr>
</table>
Where:
* `some-element` Any element which can generate DOM events (or has an angular directive which generates the event).
* `some-event` (escaped with `()` or `on-`) is the name of the event `some-event`. In this case the
dash-case is converted into camel-case `someEvent`.
* `statement` is a valid statement (as defined in section below).
If the execution of the statement returns `false`, then `preventDefault`is applied on the DOM event.
Angular listens to bubbled DOM events (as in the case of clicking on any child), as shown below:
<table>
<tr>
<th>Short form</th>
<td><pre>&lt;some-element (some-event)="statement"&gt;</pre></td>
</tr>
<tr>
<th>Canonical form</th>
<td><pre>&lt;some-element on-some-event="statement"&gt;</pre></td>
</tr>
</table>
Example:
```
@Component(...)
class Example {
submit() {
// do something when button is clicked
}
}
<button (click)="submit()">Submit</button>
```
In the above example, when clicking on the submit button angular will invoke the `submit` method on the surrounding
component's controller.
NOTE: Unlike Angular v1, Angular v2 treats event bindings as core constructs not as directives. This means that there
is no need to create an event directive for each kind of event. This makes it possible for Angular v2 to easily
bind to custom events of Custom Elements, whose event names are not known ahead of time.
## Expressions, Statements and Formatters
Angular templates contain expressions for binding to data and statements for binding to events. Expressions and statements
have different semantics.
### Expressions
Expressions can be used to bind to properties only. Expressions represent how data should be projected to the View.
Expressions should not have any side effect and should be idempotent. Examples of where expressions can be used in
Angular are:
```
<div title="{{expression}}">{{expression}}</div>
<div [title]="expression">...</div>
<div bind-title="expression">...</div>
<div template="ngIf: expression">...</div>
```
Expressions are simplified version of expression in the language in which you are writing your application. (i.e.
expressions follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike expressions in the
language, binding expressions behave differently in following ways:
* *Must be defined*: Unlike Angular v1, Angular v2 will throw an error on dereferencing fields which are not defined.
For example: `user.name` will throw an error if `user` is defined but it does not have `name` property. If the `name`
property is not known, it must be declared and set to some value such as empty string, `null` (or `undefined` in JS).
This is done to allow early detection of errors in the templates.
* *Safe dereference*: Expressions `user.name` where `user` is null will throw `NullPointerException` in the language.
In contrast Angular will silently ignore `null` on `user`. This is done because Views often have to wait for the data
to arrive from the backend and many fields will be `null` until the data arrives. Safe dereference is so common in the
Views that we have made it the default.
* *Single expression*: An expression must be a single statement. (i.e. no `;`)
* *No assignments*: Binding expressions can not contain assignments.
* *No keywords*: Binding expressions can not contain keywords such as: `var`, `if`, and so on.
* *Formatters*: Angular expressions can be piped through formatters to further transform the binding value.
(See: Formatters)
Examples of some expressions and their behavior:
Given:
```
class Greeter {
name:string;
}
```
* `name` : Will result in the value of the `name` property on the `Greeter` class.
* `name.length`: Will result in either the length of the `name` string or `undefined` (`null` in Dart) if `name`
property is `null` or `undefined`. Example of: safe dereference.
* `foo`: Will throw an error because `foo` is not declared on the `Greeter` class. Example of: Must be defined
* `name=1`: Not allowed because of assignment.
* `name; name.length`: Not allowed because of multiple statements.
### Statements
Statements can be used to bind to events only. Statements represent actions to trigger as a response to an event.
Examples of where statements can be used in Angular are:
```
<div (click)="statements">...</div>
<div on-click="statements">...</div>
```
Statements are similar to statements in the language in which you are writing your application. (i.e.
statements follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statements in the
language, binding expressions behave differently in the following ways:
* *Unsafe dereference*: Expressions `user.verify()` where `user` is `null` will throw `NullPointerException` in the
language as well as in statements. (In contrast to Safe dereference in Angular expressions.) While Angular protects
you from null dereferencing in expressions due to lazy loading of data, no such protection is required for statements,
and doing so would make it harder to detect typos in statements.
* *Multiple statements OK*: Statements can be composed from more than one statement. (i.e. no `doA(); doB()`)
* *Assignments OK*: Event bindings can have side effects and hence assignments are allowed.
* *No keywords*: Statements can not contain keywords such as: `var`, `if`, and so on.
* *No Formatters*: Angular statements can not contain formatters. (Formatters are only useful for data binding)
## Further Reading
* [Template Syntax Constraints and Reasoning](https://docs.google.com/document/d/1HHy_zPLGqJj0bHMiWPzPCxn1pO5GlOYwmv-qGgl4f_s)

378
modules/@angular/docs/core/02_directives.md Normal file
View File

@ -0,0 +1,378 @@
# Directives
Directives are classes which get instantiated as a response to a particular DOM structure. By controlling the DOM structure, what directives are imported, and their selectors, the developer can use the [composition pattern](http://en.wikipedia.org/wiki/Object_composition) to get a desirable application behavior.
Directives are the cornerstone of an Angular application. We use Directives to break complex problems into smaller more reusable components. Directives allow the developer to turn HTML into a DSL and then control the application assembly process.
Angular applications do not have a main method. Instead they have a root Component. Dependency Injection then assembles the directives into a working Angular application.
Directives with an encapsulated view and an optional injector are called *Components*.
## CSS Selectors
Directives are instantiated whenever the CSS selector matches the DOM structure.
Angular supports these CSS selector constructs:
* Element name: `name`
* Attribute: `[attribute]`
* Attribute has value: `[attribute=value]`
* Attribute contains value: `[attribute*=value]`
* Class: `.class`
* AND operation: `name[attribute]`
* OR operation: `name,.class`
* NOT operation: `:not(.class)`
Angular does not support these (and any CSS selector which crosses element boundaries):
* Descendant: `body div`
* Direct descendant: `body > div`
* Adjacent: `div + table`
* Sibling: `div ~ table`
* Wildcard: `*`
* ID: `#id`
* Pseudo selectors: `:pseudo` other than `:not`
Given this DOM:
```<input type="text" required class="primary">```
These CSS selectors will match:
* `input`: Triggers whenever element name is `input`.
* `[required]`: Triggers whenever element contains a required attribute.
* `[type=text]`: Triggers whenever element contains attribute `type` whose value is `text`.
* `.primary`: Triggers whenever element class contains `primary`.
CSS Selectors can be combined:
* `input[type=text]`: Triggers on element name `input` which is of `type` `text`.
* `input[type=text], textarea`: triggers on element name `input` which is of `type` `text` or element name `textarea`.
## Directives
The simplest kind of directive is a decorator. Directives are useful for encapsulating behavior.
* Multiple decorators can be placed on a single element.
* Directives do not introduce new evaluation context.
* Directives are registered through the `@Directive` meta-data annotation.
Here is a trivial example of a tooltip decorator. The directive will log a tooltip into the console on every time mouse enters a region:
```
@Directive({
selector: '[tooltip]', | CSS Selector which triggers the decorator
properties: [ | List which properties need to be bound
'text: tooltip' | - DOM element tooltip property should be
], | mapped to the directive text property.
host: { | List which events need to be mapped.
'(mouseover)': 'show()' | - Invoke the show() method every time
} | the mouseover event is fired.
}) |
class Form { | Directive controller class, instantiated
| when CSS matches.
text:string; | text property on the Directive Controller.
|
show() { | Show method which implements the show action.
console.log(this.text); |
}
}
```
Example of usage:
```<span tooltip="Tooltip text goes here.">Some text here.</span>```
The developer of an application can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative behavior.
Notice that data binding will work with this decorator with no further effort as shown below.
```<span tooltip="Greetings {{user}}!">Some text here.</span>```
## Components
Component is a directive which uses shadow DOM to create encapsulate visual behavior. Components are typically used to create UI widgets or to break up the application into smaller components.
* Only one component can be present per DOM element.
* Component's CSS selectors usually trigger on element names. (Best practice)
* Component has its own shadow view which is attached to the element as a Shadow DOM.
* Shadow view context is the component instance. (i.e. template expressions are evaluated against the component instance.)
>> TODO(misko): Configuring the injector
Example of a component:
```
@Component({ | Component annotation
selector: 'pane', | CSS selector on <pane> element
properties: [ | List which property need to be bound
'title', | - title mapped to component title
'open' | - open attribute mapped to component's open property
], |
templateUrl: 'pane.html' | URL of template HTML
}) |
class Pane { | Component controller class
title:string; | - title property
open:boolean;
constructor() {
this.title = '';
this.open = true;
}
// Public API
toggle() => this.open = !this.open;
open() => this.open = true;
close() => this.open = false;
}
```
`pane.html`:
```
<div class="outer">
<h1>{{title}}</h1>
<div class="inner" [hidden]="!open">
<ng-content></ng-content>
</div>
</div>
```
`pane.css`:
```
.outer, .inner { border: 1px solid blue;}
.h1 {background-color: blue;}
```
Example of usage:
```
<pane #pane title="Example Title" open="true">
Some text to wrap.
</pane>
<button (click)="pane.toggle()">toggle</button>
```
## Directives that use a ViewContainer
Directives that use a ViewContainer can control instantiation of child views which are then inserted into the DOM. (Examples are `ngIf` and `ngFor`.)
* Every `template` element creates a `ProtoView` which can be used to create Views via the ViewContainer.
* The child views show up as siblings of the directive in the DOM.
>> TODO(misko): Relationship with Injection
>> TODO(misko): Instantiator can not be injected into child Views
```
@Directive({
selector: '[if]',
properties: [
'condition: if'
]
})
export class If {
viewContainer: ViewContainerRef;
protoViewRef: ProtoViewRef;
view: View;
constructor(viewContainer: ViewContainerRef, protoViewRef: ProtoViewRef) {
this.viewContainer = viewContainer;
this.protoViewRef = protoViewRef;
this.view = null;
}
set condition(value) {
if (value) {
if (this.view === null) {
this.view = this.viewContainer.create(protoViewRef);
}
} else {
if (this.view !== null) {
this.viewContainer.remove(this.view);
this.view = null;
}
}
}
}
```
## Dependency Injection
Dependency Injection (DI) is a key aspect of directives. DI allows directives to be assembled into different [compositional](http://en.wikipedia.org/wiki/Object_composition) hierarchies. Angular encourages [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance) in the application design (but inheritance based approaches are still supported).
When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembling the directives in different order and subtypes the application behavior can be controlled. A good mental model is that the DOM structure controls the directive instantiation graph.
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. In a directive's constructor, it can ask for other directives or application services. When asking for directives, the dependency is attempted to be located by its DOM hierarchy first, then if not found, by using the application level injector.
To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
### Injecting Services
Service injection is the most straight forward kind of injection which Angular supports. It involves a component configuring the `bindings` or `viewBindings` and then letting the directive ask for the configured service.
This example illustrates how to inject `MyService` into `House` directive.
```
class MyService {} | Assume a service which needs to be injected
| into a directive.
|
@Component({ | Assume a top level application component which
selector: 'my-app', | configures the services to be injected.
viewBindings: [MyService], |
templateUrl: 'my_app.html', | Assume we have a template that needs to be
directives: [House] | configured with directives to be injected.
}) |
class MyApp {} |
|
@Directive({ | This is the directive into which we would like
selector: '[house]' | to inject the MyService.
}) |
class House { |
constructor(myService:MyService) { | Notice that in the constructor we can simply
} | ask for MyService.
} |
```
Assume the following DOM structure for `my_app.html`:
```
<div house> | The house attribute triggers the creation of the House directive.
</div> | This is equivalent to:
| new House(injector.get(MyService));
```
### Injecting other Directives
Injecting other directives into directives follows a similar mechanism as injecting services into directives, but with added constraint of visibility governed by DOM structure.
There are five kinds of visibilities:
* (no annotation): Inject dependent directives only if they are on the current element.
* `@SkipSelf()`: Inject a directive if it is at any element above the current element.
* `@child`: Inject a list of direct children which match a given type. (Used with `Query`)
* `@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
NOTE: if the injection constraint can not be satisfied by the current visibility constraint, then it is forwarded to the normal injector which either provides a default value for the directive or throws an error.
Here is an example of the kinds of injections which can be achieved:
```
@Component({ |
selector: 'my-app' |
templateUrl: 'my_app.html', |
directives: [Form, FieldSet, |
Field, Primary] |
}) |
class MyApp {} |
|
@Directive({ selector: 'form' }) |
class Form { |
constructor( |
@descendant sets:Query<FieldSet> |
) { |
} |
} |
|
@Directive({ selector: 'fieldset' }) |
class FieldSet { |
constructor( |
@child sets:Query<Field> |
) { ... } |
} |
|
@Directive({ selector: 'field' }) |
class Field { |
constructor( |
@SkipSelf() field:Form, |
@SkipSelf() field:FieldSet, |
) { ... } |
} |
|
@Directive({ selector: '[primary]'}) |
class Primary { |
constructor(field:Field ) { ... } |
} |
```
Assume the following DOM structure for `my_app.html`:
```
<form> |
<div> |
<fieldset> |
<field primary></field> |
<field></field> |
</fieldset> |
</div> |
</form> |
```
#### Shadow DOM effects on Directive DI
Shadow DOM provides an encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundaries. To remedy this, declaratively specify the required component as an injectable.
```
@Component({
selector: '[kid]'
templateUrl: 'kid.html',
directives: []
})
class Kid {
constructor(
@SkipSelf() dad:Dad,
@Optional() grandpa:Grandpa
) {
this.name = 'Billy';
this.dad = dad.name;
this.grandpa = grandpa.name;
}
}
@Component({
selector: '[dad]'
templateUrl: 'dad.html',
directives: [Kid]
})
class Dad {
constructor(@SkipSelf() dad:Grandpa) {
this.name = 'Joe Jr';
this.dad = dad.name;
}
}
@Component({
selector: '[grandpa]',
viewBindings: [],
templateUrl: 'grandpa.html',
directives: [Dad]
})
class Grandpa {
constructor() {
this.name = 'Joe';
}
}
```
Assume the following DOM structure for `grandpa.html`: The Dad has access to the Grandpa.
```
Name: {{name}}: <br> Children: <div dad></div>
```
Assume the following DOM structure for `dad.html`: Here the rendered Kid will also have access to Grandpa.
```
Name: {{name}}: <br> Dad: {{dad}} <br> Children: <div kid></div>
```
## Further Reading
* [Composition](http://en.wikipedia.org/wiki/Object_composition)
* [Composition over Inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance)

27
modules/@angular/docs/core/03_pipes.md Normal file
View File

@ -0,0 +1,27 @@
# Pipes
Pipes can be appended on the end of the expressions to translate the value to a different format. Typically used
to control the stringification of numbers, dates, and other data, but can also be used for ordering, mapping, and
reducing arrays. Pipes can be chained.
NOTE: Pipes are known as filters in Angular v1.
Pipes syntax is:
```
<div class="movie-copy">
<p>
{{ model.getValue('copy') | async | uppercase }}
</p>
<ul>
<li>
<b>Starring</b>: {{ model.getValue('starring') | async }}
</li>
<li>
<b>Genres</b>: {{ model.getValue('genres') | async }}
</li>
<ul>
</div>
```

0
modules/@angular/docs/core/04_decorator_directive.md Normal file
View File

5
modules/@angular/docs/core/05_component_directive.md Normal file
View File

@ -0,0 +1,5 @@
# Components
* Different kinds of injections and visibility
* Shadow DOM usage
*

0
modules/@angular/docs/core/06_viewport_directive.md Normal file
View File

0
modules/@angular/docs/core/07_services.md Normal file
View File

0
modules/@angular/docs/core/08_lifecycle.md Normal file
View File

21
modules/@angular/docs/core/09_compilation.md Normal file
View File

@ -0,0 +1,21 @@
# HTML Template Compilation
* Process by which a HTML template is converted to a ProtoView
1. DOM parse()
2. Macro
3.
# HTML Template
* https://docs.google.com/document/d/1HHy_zPLGqJj0bHMiWPzPCxn1pO5GlOYwmv-qGgl4f_s
* https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI
* https://docs.google.com/document/d/1DuFQKElIq293FlhQHvAp__NfP1XV9r8femZFMigm4-k
* Must understand without understanding directives
* IDE support
* local variables
# Binding Philosophy
# Binding to Shadow DOM

246
modules/@angular/docs/core/10_view.md Normal file
View File

@ -0,0 +1,246 @@
# View
## Overview
This document explains the concept of a View.
A View is a core primitive used by angular to render the DOM tree.
A ViewContainer is location in a View which can accept child Views.
Every ViewContainer has an associated ViewContainerRef than can contain any number of child Views.
Views form a tree structure which mimics the DOM tree.
* View is a core rendering construct. A running application is just a collection of Views which are
nested in a tree like structure. The View tree is a simplified version of the DOM tree. A View can
have a single DOM Element or large DOM structures. The key is that the DOM tree in the View can
not undergo structural changes (only property changes).
* Views represent a running instance of a DOM View. This implies that while elements in a View
can change properties, they can not change structurally. (Structural changes such as, adding or
removing elements requires adding or removing child Views into ViewContainers).
* View can have zero or more ViewContainers. A ViewContainer is a marker in the DOM which allows
the insertion of child Views.
* Views are created from a ProtoView. A ProtoView is a compiled DOM View which is efficient at
creating Views.
* View contains a context object. The context represents the object instance against which all
expressions are evaluated.
* View contains a ChangeDetector for looking for detecting changes to the model.
* View contains ElementInjector for creating Directives.
## Simple View
Let's examine a simple View and all of its parts in detail.
Assume the following Component:
```
class Greeter {
greeting:string;
constructor() {
this.greeting = 'Hello';
}
}
```
And assume following HTML View:
```
<div>
Your name:
<input var="name" type="Text">
<br>
{{greeting}} {{name.value}}!
</div>
```
The above template is compiled by the Compiler to create a ProtoView. The ProtoView is then used to
create an instance of the View. The instantiation process involves cloning the above template and
locating all of the elements which contain bindings and finally instantiating the Directives
associated with the template. (See compilation for more details.)
```
<div> | viewA(greeter)
Your name: | viewA(greeter)
<input var="name" type="Text"> | viewA(greeter): local variable 'name'
<br> | viewA(greeter)
{{greeting}} {{name.value}}! | viewA(greeter): binding expression 'greeting' & 'name.value'
</div> | viewA(greeter)
```
The resulting View instance looks something like this (simplified pseudo code):
```
viewA = new View({
template: ...,
context: new Greeter(),
localVars: ['name'],
watchExp: ['greeting', 'name.value']
});
```
Note:
* View uses instance of `Greeter` as the evaluation context.
* View knows of local variables `name`.
* View knows which expressions need to be watched.
* View knows what needs to be updated if the watched expression changes.
* All DOM elements are owned by single instance of the view.
* The structure of the DOM can not change during runtime. To allow structural changes to the DOM we need
to understand Composed View.
## Composed View
An important part of an application is to be able to change the DOM structure to render data for the
user. In Angular this is done by inserting child views into the ViewContainer.
Let's start with a View such as:
```
<ul>
<li template="ngFor: let person of people">{{person}}</li>
</ul>
```
During the compilation process the Compiler breaks the HTML template into these two ProtoViews:
```
<li>{{person}}</li> | protoViewB(Locals)
```
and
```
<ul> | protoViewA(someContext)
<template></template> | protoViewA(someContext): protoViewB
</ul> | protoViewA(someContext)
```
The next step is to compose these two ProtoViews into an actual view which is rendered to the user.
*Step 1:* Instantiate `viewA`
```
<ul> | viewA(someContext)
<template></template> | viewA(someContext): new NgFor(new ViewContainer(protoViewB))
</ul> | viewA(someContext)
```
*Step2:* Instantiate `NgFor` directive which will receive the `ViewContainerRef`. (The ViewContainerRef
has a reference to `protoViewA`).
*Step3:* As the `NgFor` directive unrolls it asks the `ViewContainerRef` to instantiate `protoViewB` and insert
it after the `ViewContainer` anchor. This is repeated for each `person` in `people`. Notice that
```
<ul> | viewA(someContext)
<template></template> | viewA(someContext): new NgFor(new ViewContainer(protoViewB))
<li>{{person}}</li> | viewB0(locals0(someContext))
<li>{{person}}</li> | viewB1(locals0(someContext))
</ul> | viewA(someContext)
```
*Step4:* All of the bindings in the child Views are updated. Notice that in the case of `NgFor`
the evaluation context for the `viewB0` and `viewB1` are `locals0` and `locals1` respectively.
Locals allow the introduction of new local variables visible only within the scope of the View, and
delegate any unknown references to the parent context.
```
<ul> | viewA
<template></template> | viewA: new NgFor(new ViewContainer(protoViewB))
<li>Alice</li> | viewB0
<li>Bob</li> | viewB1
</ul> | viewA
```
Each View can have zero or more ViewContainers. By inserting and removing child Views to and from the
ViewContainers, the application can mutate the DOM structure to any desirable state. A View may contain
individual nodes or a complex DOM structure. The insertion points for the child Views, known as
ViewContainers, contain a DOM element which acts as an anchor. The anchor is either a `template` or
a `script` element depending on your browser. It is used to identify where the child Views will be
inserted.
## Component Views
A View can also contain Components. Components contain Shadow DOM for encapsulating their internal
rendering state. Unlike ViewContainers which can contain zero or more Views, the Component always contains
exactly one Shadow View.
```
<div> | viewA
<my-component> | viewA
#SHADOW_ROOT | (encapsulation boundary)
<div> | viewB
encapsulated rendering | viewB
</div> | viewB
</my-component> | viewA
</div> | viewA
```
## Evaluation Context
Each View acts as a context for evaluating its expressions. There are two kinds of contexts:
1. A component controller instance and
2. a `Locals` context for introducing local variables into the View.
Let's assume following component:
```
class Greeter {
greeting:string;
constructor() {
this.greeting = 'Hello';
}
}
```
And assume the following HTML View:
```
<div> | viewA(greeter)
Your name: | viewA(greeter)
<input var="name" type="Text"> | viewA(greeter)
<br> | viewA(greeter)
{{greeting}} {{name.value}}! | viewA(greeter)
</div> | viewA(greeter)
```
The above UI is built using a single View, and hence a single context `greeter`. It can be expressed
in this pseudo-code.
```
var greeter = new Greeter();
```
The View contains two bindings:
1. `greeting`: This is bound to the `greeting` property on the `Greeter` instance.
2. `name.value`: This poses a problem. There is no `name` property on the `Greeter` instance. To solve
this we wrap the `Greeter` instance in the `Local` instance like so:
```
var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
```
By wrapping the `Greeter` instance into the `Locals` we allow the view to introduce variables which
are in addition to the `Greeter` instance. During the resolution of the expressions we first check
the locals, and then the `Greeter` instance.
## View LifeCycle (Hydration and Dehydration)
Views transition through a particular set of states:
1. View is created from the ProtoView.
2. View can be attached to an existing ViewContainerRef.
3. Upon attaching View to the ViewContainerRef the View needs to be hydrated. The hydration process
involves instantiating all of the Directives associated with the current View.
4. At this point the view is ready and renderable. Multiple changes can be delivered to the
Directives from the ChangeDetection.
5. At some point the View can be removed. At this point all of the directives are destroyed during
the dehydration process and the view becomes inactive.
6. The View has to wait until it is detached from the DOM. The delay in detaching could be caused
because an animation is animating the view away.
7. After the View is detached from the DOM it is ready to be reused. The view reuse allows the
application to be faster in subsequent renderings.

0
modules/@angular/docs/core/11_shadow_dom.md Normal file
View File

108
modules/@angular/docs/core/12_zones.md Normal file
View File

@ -0,0 +1,108 @@
# Zones
A Zone is an execution context that persists across async tasks. You can think of it as thread-local storage for
JavaScript. Zones are used to intercept all async operation callbacks in the browser. By intercepting async
callbacks Angular can automatically execute the change detection at the end of the VM turn to update the application
UI bindings. Zones means that in Angular v2 you don't have to remember to call `rootScope.$apply()` in your async call.
## Execution Context
```
zone.inTheZone = false;
zone.fork().run(function () {
zone.inTheZone = true;
setTimeout(function () {
console.log('async in the zone: ' + zone.inTheZone);
}, 0);
});
console.log('sync in the zone: ' + zone.inTheZone);
```
The above will log:
```
sync in the zone: false
async in the zone: true
```
In the above example the `zone` is a global-callback-local variable. To the `zone` we can attach arbitrary properties
such as `inTheZone`. When we enter the zone, we get a new `zone` context (which inherits all properties from the
parent zone), once we leave the zone, the previous `zone` variable is restored. The key part is that when a async
callback is scheduled in the zone, as is the case with `setTimeout`, the current `zone` variable is captured and
restored on the callback. This is why the output of the `inTheZone` property inside the callback of the `setTimeout`
prints `true`.
## Callback Interception
In addition to storing properties on the current `zone`, zones can also allow us to intercept all async callbacks
and notify us before and after the callback executes.
```
zone.fork({
afterTask: function () {
// do some cleanup
}
}).run(function () {
// do stuff
});
```
The above example will execute the `afterTask` function not only after the `run` finishes, but also after any callback
execution which was registered in the `run` block.
## Putting it all together in Angular
In Angular2 it is not necessary to notify Angular of changes manually after async callback, because a relevant
async callbacks are intercepted. The question is how do we know which callbacks are Angular relevant?
// TODO(vicb): outdated, rework.
```
/// Some other code running on page can do async operation
document.addEventListener('mousemove', function () {
console.log('Mouse moved.');
});
var AngularZone = {
afterTask: function () {
console.log('ANGULAR AUTO-DIGEST!');
}
};
var ngZone = zone.fork(AngularZone);
ngZone.run(function() {
console.log('I aware of angular, I should cause digest.');
document.addEventListener('click', function () {
console.log('Mouse clicked.');
});
});
```
Will produce:
```
I aware of angular, I should cause digest.
ANGULAR AUTO-DIGEST!
```
Moving the mouse will produce many:
```
Mouse moved.
```
But clicking will produce:
```
Mouse clicked.
ANGULAR AUTO-DIGEST!
```
Notice how the place where the listener was registered will effect whether or not Angular will be notified of the
async call and cause a change detection to run to update the UI.
Being able to globally intercept the async operation is important to have a seamless integration with all existing
libraries. But it is equally important to be able to differentiate between Angular and non-Angular code running
on the same page concurrently.

267
modules/@angular/docs/di/di.md Normal file
View File

@ -0,0 +1,267 @@
# Dependency Injection (DI): Documentation
This document describes in detail how the DI module works in Angular 2.
## Core Abstractions
The library is built on top of the following core abstractions: `Injector`, `Binding`, and `Dependency`.
* An injector is created from a set of bindings.
* An injector resolves dependencies and creates objects.
* A binding maps a token, such as a string or class, to a factory function and a list of dependencies. So a binding defines how to create an object.
* A dependency points to a token and contains extra information on how the object corresponding to that token should be injected.
```
[Injector]
|
|
|*
[Binding]
|----------|-----------------|
| | |*
[Token] [FactoryFn] [Dependency]
|---------|
| |
[Token] [Flags]
```
## Example
```
class Engine {
}
class Car {
constructor(@Inject(Engine) engine) {
}
}
var inj = Injector.resolveAndCreate([
bind(Car).toClass(Car),
bind(Engine).toClass(Engine)
]);
var car = inj.get(Car);
```
In this example we create two bindings: one for `Car` and one for `Engine`. `@Inject(Engine)` declares a dependency on Engine.
## Injector
An injector instantiates objects lazily, only when asked for, and then caches them.
Compare
```
var car = inj.get(Car); //instantiates both an Engine and a Car
```
with
```
var engine = inj.get(Engine); //instantiates an Engine
var car = inj.get(Car); //instantiates a Car (reuses Engine)
```
and with
```
var car = inj.get(Car); //instantiates both an Engine and a Car
var engine = inj.get(Engine); //reads the Engine from the cache
```
To avoid bugs make sure the registered objects have side-effect-free constructors. In this case, an injector acts like a hash map, where the order in which the objects got created does not matter.
## Child Injectors and Dependencies
Injectors are hierarchical.
```
var parent = Injector.resolveAndCreate([
bind(Engine).toClass(TurboEngine)
]);
var child = parent.resolveAndCreateChild([Car]);
var car = child.get(Car); // uses the Car binding from the child injector and Engine from the parent injector.
```
Injectors form a tree.
```
GrandParentInjector
/ \
Parent1Injector Parent2Injector
|
ChildInjector
```
The dependency resolution algorithm works as follows:
```
// this is pseudocode.
var inj = this;
while (inj) {
if (inj.hasKey(requestedKey)) {
return inj.get(requestedKey);
} else {
inj = inj.parent;
}
}
throw new NoProviderError(requestedKey);
```
So in the following example
```
class Car {
constructor(e: Engine){}
}
```
DI will start resolving `Engine` in the same injector where the `Car` binding is defined. It will check whether that injector has the `Engine` binding. If it is the case, it will return that instance. If not, the injector will ask its parent whether it has an instance of `Engine`. The process continues until either an instance of `Engine` has been found, or we have reached the root of the injector tree.
### Constraints
You can put upper and lower bound constraints on a dependency. For instance, the `@Self` decorator tells DI to look for `Engine` only in the same injector where `Car` is defined. So it will not walk up the tree.
```
class Car {
constructor(@Self() e: Engine){}
}
```
A more realistic example is having two bindings that have to be provided together (e.g., NgModel and NgRequiredValidator.)
The `@Host` decorator tells DI to look for `Engine` in this injector, its parent, until it reaches a host (see the section on hosts.)
```
class Car {
constructor(@Host() e: Engine){}
}
```
The `@SkipSelf` decorator tells DI to look for `Engine` in the whole tree starting from the parent injector.
```
class Car {
constructor(@SkipSelf() e: Engine){}
}
```
### DI Does Not Walk Down
Dependency resolution only walks up the tree. The following will throw because DI will look for an instance of `Engine` starting from `parent`.
```
var parent = Injector.resolveAndCreate([Car]);
var child = parent.resolveAndCreateChild([
bind(Engine).toClass(TurboEngine)
]);
parent.get(Car); // will throw NoProviderError
```
## Bindings
You can bind to a class, a value, or a factory. It is also possible to alias existing bindings.
```
var inj = Injector.resolveAndCreate([
bind(Car).toClass(Car),
bind(Engine).toClass(Engine)
]);
var inj = Injector.resolveAndCreate([
Car, // syntax sugar for bind(Car).toClass(Car)
Engine
]);
var inj = Injector.resolveAndCreate([
bind(Car).toValue(new Car(new Engine()))
]);
var inj = Injector.resolveAndCreate([
bind(Car).toFactory((e) => new Car(e), [Engine]),
bind(Engine).toFactory(() => new Engine())
]);
```
You can bind any token.
```
var inj = Injector.resolveAndCreate([
bind(Car).toFactory((e) => new Car(), ["engine!"]),
bind("engine!").toClass(Engine)
]);
```
If you want to alias an existing binding, you can do so using `toAlias`:
```
var inj = Injector.resolveAndCreate([
bind(Engine).toClass(Engine),
bind("engine!").toAlias(Engine)
]);
```
which implies `inj.get(Engine) === inj.get("engine!")`.
Note that tokens and factory functions are decoupled.
```
bind("some token").toFactory(someFactory);
```
The `someFactory` function does not have to know that it creates an object for `some token`.
### Resolved Bindings
When DI receives `bind(Car).toClass(Car)`, it needs to do a few things before it can create an instance of `Car`:
- It needs to reflect on `Car` to create a factory function.
- It needs to normalize the dependencies (e.g., calculate lower and upper bounds).
The result of these two operations is a `ResolvedBinding`.
The `resolveAndCreate` and `resolveAndCreateChild` functions resolve passed-in bindings before creating an injector. But you can resolve bindings yourself using `Injector.resolve([bind(Car).toClass(Car)])`. Creating an injector from pre-resolved bindings is faster, and may be needed for performance sensitive areas.
You can create an injector using a list of resolved bindings.
```
var listOfResolvingBindings = Injector.resolve([Binding1, Binding2]);
var inj = Injector.fromResolvedBindings(listOfResolvingBindings);
inj.createChildFromResolvedBindings(listOfResolvedBindings);
```
### Transient Dependencies
An injector has only one instance created by each registered binding.
```
inj.get(MyClass) === inj.get(MyClass); //always holds
```
If we need a transient dependency, something that we want a new instance of every single time, we have two options.
We can create a child injector for each new instance:
```
var child = inj.resolveAndCreateChild([MyClass]);
child.get(MyClass);
```
Or we can register a factory function:
```
var inj = Injector.resolveAndCreate([
bind('MyClassFactory').toFactory(dep => () => new MyClass(dep), [SomeDependency])
]);
var factory = inj.get('MyClassFactory');
var instance1 = factory(), instance2 = factory();
// Depends on the implementation of MyClass, but generally holds.
expect(instance1).not.toBe(instance2);
```

235
modules/@angular/docs/di/di_advanced.md Normal file
View File

@ -0,0 +1,235 @@
# Dependency Injection (DI): Documentation (Advanced Topics)
This document talks about advanced topics related to the DI module and how it is used in Angular. You don't have to know this to use DI in Angular or independently.
### Key
Most of the time we do not have to deal with keys.
```
var inj = Injector.resolveAndCreate([
bind(Engine).toFactory(() => new TurboEngine()) //the passed in token Engine gets mapped to a key
]);
var engine = inj.get(Engine); //the passed in token Engine gets mapped to a key
```
Now, the same example, but with keys.
```
var ENGINE_KEY = Key.get(Engine);
var inj = Injector.resolveAndCreate([
bind(ENGINE_KEY).toFactory(() => new TurboEngine()) // no mapping
]);
var engine = inj.get(ENGINE_KEY); // no mapping
```
Every key has an id, which we utilize to store bindings and instances. So Injector uses keys internally for performance reasons.
### ProtoInjector and Injector
Often there is a need to create multiple instances of essentially the same injector. In Angular 2, for example, every component element type gets an injector configured in the same way.
Doing the following would be very inefficient.
```
function createComponetInjector(parent, bindings: Binding[]) {
return parent.resolveAndCreateChild(bindings);
}
```
This would require us to resolve and store bindings for every single component instance. Instead, we want to resolve and store the bindings for every component type, and create a set of instances for every component. To enable that DI separates the meta information about injectables (Bindings and their dependencies), which are stored in `ProtoInjector`, and injectables themselves, which are stored in `Injector`.
```
var proto = new ProtoInjector(bindings); // done once
function createComponentInjector(parent, proto) {
return new Injector(proto, parent);
}
```
`Injector.resolveAndCreate` creates both a `ProtoInjector` and an `Injector`.
### Host & Visibility
An injector can have a parent. The parent relationship can be marked as a "host" as follows:
```
var child = new Injector(proto, parent, true /* host */);
```
Hosts are used to constraint dependency resolution. For instance, in the following example, DI will stop looking for `Engine` after reaching the host.
```
class Car {
constructor(@Host() e: Engine) {}
}
```
Imagine the following scenario:
```
ParentInjector
/ \
/ \ host
Child1 Child2
```
Here both Child1 and Child2 are children of ParentInjector. Child2 marks this relationship as host. ParentInjector might want to expose two different sets of bindings for its "regular" children and its "host" children. Bindings visible to "regular" children are called "public" and bindings visible to "host" children are called "private". This is an advanced use case used by Angular, where components can provide different sets of bindings for their children and their view.
Let's look at this example.
```
class Car {
constructor(@Host() e: Engine) {}
}
var parentProto = new ProtoInjector([
new BindingWithVisibility(Engine, Visibility.Public),
new BindingWithVisibility(Car, Visibility.Public)
]);
var parent = new Injector(parentProto);
var hostChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var hostChild = new Injector(hostChildProto, parent, true);
var regularChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var regularChild = new Injector(regularChildProto, parent, false);
hostChild.get(Car); // will throw because public dependencies declared at the host cannot be seen by child injectors
parent.get(Car); // this works
regularChild.get(Car); // this works
```
Now, let's mark `Engine` as private:
```
class Car {
constructor(@Host() e: Engine) {}
}
var parentProto = new ProtoInjector([
new BindingWithVisibility(Engine, Visibility.Private),
new BindingWithVisibility(Car, Visibility.Public)
]);
var parent = new Injector(parentProto);
var hostChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var hostChild = new Injector(hostChildProto, parent, true);
var regularChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var regularChild = new Injector(regularChildProto, parent, false);
hostChild.get(Car); // this works
parent.get(Car); // this throws
regularChild.get(Car); // this throws
```
Now, let's mark `Engine` as both public and private:
```
class Car {
constructor(@Host() e: Engine) {}
}
var parentProto = new ProtoInjector([
new BindingWithVisibility(Engine, Visibility.PublicAndPrivate),
new BindingWithVisibility(Car, Visibility.Public)
]);
var parent = new Injector(parentProto);
var hostChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var hostChild = new Injector(hostChildProto, parent, true);
var regularChildProto = new ProtoInjector([new BindingWithVisibility(Car, Visibility.Public)]);
var regularChild = new Injector(regularChildProto, parent, false);
hostChild.get(Car); // this works
parent.get(Car); // this works
regularChild.get(Car); // this works
```
## Angular 2 and DI
Now let's see how Angular 2 uses DI behind the scenes.
The right mental model is to think that every DOM element has an Injector. (In practice, only interesting elements containing directives will have an injector, but this is a performance optimization)
There are two properties that can be used to configure DI: bindings and viewBindings.
- `bindings` affects the element and its children.
- `viewBindings` affects the component's view.
Every directive can declare injectables via `bindings`, but only components can declare `viewBindings`.
Let's look at a complex example that shows how the injector tree gets created.
```
<my-component my-directive>
<needs-service></needs-service>
</my-component>
```
Both `MyComponent` and `MyDirective` are created on the same element.
```
@Component({
selector: 'my-component',
bindings: [
bind('componentService').toValue('Host_MyComponentService')
],
viewBindings: [
bind('viewService').toValue('View_MyComponentService')
],
template: `<needs-view-service></needs-view-service>`,
directives: [NeedsViewService]
})
class MyComponent {}
@Directive({
selector: '[my-directive]',
bindings: [
bind('directiveService').toValue('MyDirectiveService')
]
})
class MyDirective {
}
```
`NeedsService` and `NeedsViewService` look like this:
```
@Directive({
selector: 'needs-view-service'
})
class NeedsViewService {
constructor(@Host() @Inject('viewService') viewService) {}
}
@Directive({
selector: 'needs-service'
})
class NeedsService {
constructor(@Host() @Inject('componentService') service1,
@Host() @Inject('directiveService') service2) {}
}
```
This will create the following injector tree.
```
Injector1 [
{binding: MyComponent, visibility: Visibility.PublicAndPrivate},
{binding: 'componentService', visibility: Visibility.PublicAndPrivate},
{binding: 'viewService', visibility: Visibility.Private},
{binding: MyDirective visibility: Visibility.Public},
{binding: 'directiveService', visibility: Visibility.Public}
]
/ \
| \ host
Injector2 [ Injector3 [
{binding: NeedsService, visibility: Visibility.Public} {binding: NeedsViewService, visibility: Visibility.Public}
] ]
```
As you can see the component and its bindings can be seen by its children and its view. The view bindings can be seen only by the view. And the bindings of other directives can be seen only their children.

239
modules/@angular/docs/migration/kebab-case.md Normal file
View File

@ -0,0 +1,239 @@
Angular2 templates are now case-sensitive and use camelCase in many places where dash-case was previously used ([design doc] (https://docs.google.com/document/d/1UMxTIUBTIUZNfOqwMhkLg0ANFSBtLIK9JsIu77EZaBA/edit?ts=564f7dd4)).
## Overview
Where you used to write:
```
<my-cmp (some-event)="someAction()" [some-property]="expression" #some-var>
```
in order to:
- bind to the `someEvent` event,
- bind to the `someProperty` property,
- create a `someVar` local variable
You should now write:
```
<my-cmp (someEvent)="someAction()" [someProperty]="expression" #someVar>
```
Notes:
- while tag name are case sensitive, the best practice is to use dash case for component elements so that the browser
interpret them as custom elements,
- `(some-event)` would now bind to the `some-event` event (i.e. there is no implicit dash to camel case conversion),
- `[some-property]` would now bind to the `some-property` property (i.e. there is no implicit dash to camel case conversion),
- `#some-var` is not allowed any more ("-" can not be used in variable names).
## Migration
#### Templates
1. Directives selectors, property bindings, event bindings, template variables and template element attributes should be changed to camel case:
Examples:
- `<p *ng-if="cond">` should be changed to `<p *ngIf="cond">`,
- `<my-cmp [my-prop]="exp">` should be changed to `<my-cmp [myProp]="exp">`,
- `<my-cmp (my-event)="action()">` should be changed to `<my-cmp (myEvent)="action()">`,
- `<my-cmp [(my-prop)]="prop">` should be changed to `<my-cmp [(myProp)]="prop">`,
- `<input #my-input>` should be changed to `<input #myInput>`,
- `<template ng-for #my-item [ng-for-of]=items #my-index="index">` should be changed to `<template ngFor #myItem [ngForOf]=items #myIndex="index">`,
Note: while the tag names are now case-sensitive the best practice is to keep them lower-dash-cased so that the browser
treat them as custom elements. Using dashes in custom element names is required by the [Custom Element HTML Spec](http://www.w3.org/TR/custom-elements/#concepts).
This explains why the `<router-outlet>` component is left unchanged.
`on-`, `bindon-`, `bind-` and `var-` prefixes are still part of the canonical syntax and should remain unchanged (lower cased):
- `on-some-event` should be changed to `on-someEvent`,
- `bind-my-prop` should be changed to `bind-myProp`,
- `bindon-my-prop` should be changed to `bindon-myProp`,
- `var-my-var` should be changed to `var-myVar`.
2. Update variable binding
- `<p #var1="a-b" var-var2="c-d">` should be changed to `<p #var1="aB" var-var2="cD">`
3. The `template` attribute values should also be updated in the same way
`<p template="ng-for #my-item of items #my-index = index">` should be changed to `<p template="ngFor #myItem of items #myIndex = index">`.
Note that both angular directives and your own directives must be updated in the same way.
#### Directives and Components
Take the following steps to upgrade your directives and components:
1. Update the selector:
```
@Directive({selector: 'tag[attr][name=value]'})
@Component({selector: 'tag[attr][name=value]'})
```
Tag and attributes names are case sensitive:
- For tag names, the best practice is to keep them lower dash cased, do not update them,
- For attribute names, the best practice is to convert them from lower dash case to camel case.
Examples:
- `custom-tag` should stay `custom-tag` (do not update tag names),
- `[attr-name]` should be updated to `[attrName]`,
- `[attr-name=someValue]` should be updated to `[attrName=someValue]`,
- `custom-tag[attr-name=someValue]` should be updated to `custom-tag[attrName=someValue]`
Note: attribute values and classes are still matched case insensitive.
2. Update the inputs
```
@Directive({inputs: ['myProp', 'myOtherProp: my-attr-name']})
```
As attribute names are now case sensitive, they should be converted from dash to camel case where they are specified.
The previous decorator becomes:
```
@Directive({inputs: ['myProp', 'myOtherProp: myAttrName']})
```
Notes:
- only the long syntax (with ":") needs to be updated,
- `properties` is the legacy name for `inputs` and should be updated in the same way - it is a good idea to replace
`properties` with `inputs` at the same time as support for the former will be removed soon.
The same applies for the `@Input` decorator:
```
@Input() myProp;
@Input('my-attr-name') myProp;
```
That is they only need to be updated when the attribute name is specified:
```
@Input() myProp; // Nothing to update
@Input('myAttrName') myProp; // Convert the attribute name to camel case
```
3. Update the outputs
Update the outputs in the same way the inputs are updated:
```
@Directive({outputs: ['myEvent', 'myOtherEvent: my-event-name']})
```
should be updated to:
```
@Directive({outputs: ['myEvent', 'myOtherEvent: myEventName']})
```
If you use `events` instead of `outputs` you should update in the same way and switch to `outputs` as `events` is deprecated.
```
@Output() myEvent;
@Output('my-event-name') myEvent;
```
should be changed to:
```
@Output() myEvent;
@Output('myEventName') myEvent;
```
4. Update the host bindings
```
@Directive({
host: {
'[some-prop]': 'exp',
'[style.background-color]': 'exp',
'[class.some-class]': 'exp',
'[attr.some-attr]': 'exp',
'(some-event)': 'action()',
'some-attr': 'value'
}
})
```
should be changed to:
```
@Directive({
host: {
'[someProp]': 'exp',
'[style.background-color]': 'exp',
'[class.some-class]': 'exp',
'[attr.some-attr]': 'exp',
'(someEvent)': 'action()',
'some-attr': 'value'
}
})
```
The property bindings (`[...]`) and event bindings (`(...)`) must be updated in the same way as they are updated in a
template - ie converted to camel case (reminder: `[attr.]`, `[class.]` and `[style.]` should not be converted to camel case).
5. Update export name
```
@Directive({
exportAs: 'some-name'
})
```
should be changed to:
```
@Directive({
exportAs: 'someName'
})
```
# CSS
As the attribute names from your templates have been updated from dash to camel case, you should also reflect the changes
in your stylesheets.
The attributes that need to be updated are the ones used in the selector and the inputs of your directives.
Before:
```
// Directive
@Directive({
selector: '[my-dir]',
inputs: ['someProp: some-input'],
})
<!-- template -->
<div my-dir some-input="some value" not-an-input></div>
/* css */
[my-dir] { ... }
[some-input] { ... }
[not-an-input] { ... }
```
After:
```
// Directive
@Directive({
selector: '[myDir]',
inputs: ['someProp: someInput'],
})
<!-- template -->
<div myDir someInput="some value" not-an-input></div>
/* css */
[myDir] { ... }
[someInput] { ... }
[not-an-input] { ... }
```
Notes:
- `not-an-input` is not used in a selector nor it is an input of a directive, it need not be camel cased,
- CSS selectors are case insensitive you can use `[myDir]`, `[mydir]` or any other casing.

560
modules/@angular/docs/web_workers/web_workers.md Normal file
View File

@ -0,0 +1,560 @@
# WebWorkers in Angular 2: Documentation
Angular 2 includes native support for writing applications which live in a
WebWorker. This document describes how to write applications that take advantage
of this feature.
It also provides a detailed description of the underlying messaging
infrastructure that angular uses to communicate between the main process and the
worker. This infrastructure can be modified by an application developer to
enable driving an angular 2 application from an iFrame, different window / tab,
server, etc..
## Introduction
WebWorker support in Angular2 is designed to make it easy to leverage parallelization in your web application.
When you choose to run your application in a WebWorker angular runs both your application's logic and the
majority of the core angular framework in a WebWorker.
By offloading as much code as possible to the WebWorker we keep the UI thread
free to handle events, manipulate the DOM, and run animations. This provides a
better framerate and UX for applications.
## Bootstrapping a WebWorker Application
Bootstrapping a WebWorker application is not much different than bootstrapping a normal application.
The main difference is that you need to do the bootstrap process on both the worker and render thread.
Unlike in a standard Angular2 application you don't bootstrap your main component on the render thread.
Instead you initialize a new application injector with the WORKER_APP_PLATFORM providers and provide the name
of your WebWorker script. See the example below for details:
### Example
To bootstrap Hello World in a WebWorker we do the following in TypeScript
```HTML
<html>
<head>
<script src="https://cdnjs.cloudflare.com/ajax/libs/es6-shim/0.33.3/es6-shim.js"></script>
<script src="https://jspm.io/system@0.16.js"></script>
<script src="angular2/web_worker/ui.js"></script>
</head>
<body>
<hello-world></hello-world>
<script>System.import("index")</script>
</body>
</html>
```
```TypeScript
// index.js
import {WORKER_RENDER_PLATFORM, WORKER_RENDER_APPLICATION, WORKER_SCRIPT} from "angular2/platform/worker_render";
import {platform} from "angular2/core";
platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION, new Provider(WORKER_SCRIPT, {useValue: "loader.js"});
```
```JavaScript
// loader.js
importScripts("https://cdnjs.cloudflare.com/ajax/libs/es6-shim/0.33.3/es6-shim.js", "https://jspm.io/system@0.16.js", "angular2/web_worker/worker.js");
System.import("app");
```
```TypeScript
// app.ts
import {Component, View, platform} from "angular2/core";
import {WORKER_APP_PLATFORM, WORKER_APP_APPLICATION} from "angular2/platform/worker_app";
@Component({
selector: "hello-world"
})
@View({
template: "<h1>Hello {{name}}</h1>
})
export class HelloWorld {
name: string = "Jane";
}
platform([WORKER_APP_PLATFORM])
.application([WORKER_APP_APPLICATION])
.then((ref) => ref.bootstrap(RootComponent));
```
There's a few important things to note here:
* The UI loads angular from the file `angular2/web_worker/ui.js` and the Worker loads angular from
`angular2/web_worker/worker.js`. These bundles are created specifically for using WebWorkers and should be used
instead of the normal angular2.js file. Both files contain subsets of the angular2 codebase that is designed to
run specifically on the UI or Worker. Additionally, they contain the core messaging infrastructure used to
communicate between the Worker and the UI. This messaging code is not in the standard angular2.js file.
* We pass `loader.js` to our application injector using the WORKER_SCRIPT symbol. This tells angular that our WebWorkers's init script is located at `loader.js`.
You can think of `loader.js` as the index.html file for the WebWorker.
Since WebWorkers share no memory with the UI we need to reload the angular2 dependencies before
bootstrapping our application. We do this with `importScripts`. Additionally, we need to do this in a different
file than `app.ts` because our module loader (System.js in this example) has not been loaded yet, and `app.ts`
will be compiled with a `System.define` call at the top.
* The HelloWorld Component looks exactly like a normal Angular2 HelloWorld Component! The goal of WebWorker
support was to allow as much of Angular to live in the worker as possible.
As such, *most* angular2 components can be bootstrapped in a WebWorker with minimal to no changes required.
For reference, here's the same HelloWorld example in Dart.
```HTML
<html>
<body>
<script type="application/dart" src="index.dart"></script>
<script src="packages/browser.dart.js"></script>
</body>
</html>
```
```Dart
// index.dart
import "angular2/core.dart";
import "angular2/platform/worker_render.dart";
main() {
platform([WORKER_RENDER_PLATFORM])
.asyncApplication(initIsolate("my_worker.dart"));
}
```
```Dart
// background_index.dart
import "angular2/core.dart";
import "angular2/platform/worker_app.dart";
import "package:angular2/src/core/reflection/reflection.dart";
import "package:angular2/src/core/reflection/reflection_capabilities.dart";
@Component(
selector: "hello-world"
)
@View(
template: "<h1>Hello {{name}}</h1>"
)
class HelloWorld {
String name = "Jane";
}
main(List<String> args, SendPort replyTo) {
reflector.reflectionCapabilities = new ReflectionCapabilities();
platform([WORKER_APP_PLATFORM, new Provider(RENDER_SEND_PORT, useValue: replyTo)])
.application([WORKER_APP_APPLICATION])
.bootstrap(RootComponent);
}
```
This code is nearly the same as the TypeScript version with just a couple key differences:
* We don't have a `loader.js` file. Dart applications don't need this file because you don't need a module loader.
* We provide a `SendPort` through DI using the token `RENDER_SEND_PORT`. Dart applications use the Isolate API, which communicates via
Dart's Port abstraction. When you call `setupIsolate` from the UI thread, angular starts a new Isolate to run
your application logic. When Dart starts a new Isolate it passes a `SendPort` to that Isolate so that it
can communicate with the Isolate that spawned it. You need to provide this `SendPort` through DI
so that Angular can communicate with the UI.
* You need to set up `ReflectionCapabilities` on both the UI and Worker. Just like writing non-concurrent
Angular2 Dart applications you need to set up the reflector. You should not use Reflection in production,
but should use the angular 2 transformer to remove it in your final JS code. Note there's currently a bug
with running the transformer on your UI code (#3971). You can (and should) pass the file where you call
`bootstrap` as an entry point to the transformer, but you should not pass your UI index file
to the transformer until that bug is fixed.
* In dart we call `asyncApplication` instead of `application` from the render thread because starting an isolate in Dart is asyncronous
whereas starting a new WebWorker in JavaScript is a synchronous operation.
## Writing WebWorker Compatible Components
You can do almost everything in a WebWorker component that you can do in a typical Angular 2 Component.
The main exception is that there is **no** DOM access from a WebWorker component. In Dart this means you can't
import anything from `dart:html` and in JavaScript it means you can't use `document` or `window`. Instead you
should use data bindings and if needed you can inject the `Renderer` along with your component's `ElementRef`
directly into your component and use methods such as `setElementProperty`, `setElementAttribute`,
`setElementClass`, `setElementStyle`, `invokeElementMethod`, and `setText`. Note that you **cannot** call
`getNativeElementSync`. Doing so will always return `null` when running in a WebWorker.
If you need DOM access see [Running Code on the UI](#running-code-on-the-ui).
## WebWorker Design Overview
When running your application in a WebWorker, the majority of the angular core along with your application logic
runs on the worker. The two main components that run on the UI are the `Renderer` and the `RenderCompiler`. When
running angular in a WebWorker the bindings for these two components are replaced by the `WebWorkerRenderer` and
the `WebWorkerRenderCompiler`. When these components are used at runtime, they pass messages through the
[MessageBroker](#messagebroker) instructing the UI to run the actual method and return the result. The
[MessageBroker](#messagebroker) abstraction allows either side of the WebWorker boundary to schedule code to run
on the opposite side and receive the result. You can use the [MessageBroker](#messagebroker)
Additionally, the [MessageBroker](#messagebroker) sits on top of the [MessageBus](#messagebus).
MessageBus is a low level abstraction that provides a language agnostic API for communicating with angular components across any runtime boundary such as `WebWorker <--> UI` communication, `UI <--> Server` communication,
or `Window <--> Window` communication.
See the diagram below for a high level overview of how this code is structured:
![WebWorker Diagram](http://stanford.edu/~jteplitz/ng_2_worker.png)
## Running Code on the UI
If your application needs to run code on the UI, there are a few options. The easiest way is to use a
CustomElement in your view. You can then register this custom element from your html file and run code in response
to the element's lifecycle hooks. Note, Custom Elements are still experimental. See
[MDN](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements) for the latest details on how
to use them.
If you require more robust communication between the WebWorker and the UI you can use the [MessageBroker](#using-the-messagebroker-in-your-application) or
[MessageBus](#using-the-messagebus-in-your-application) directly.
## MessageBus
The MessageBus is a low level abstraction that provides a language agnostic API for communicating with angular components across any runtime boundary. It supports multiplex communication through the use of a channel
abstraction.
Angular currently includes two stable MessageBus implementations, which are used by default when you run your
application inside a WebWorker.
1. The `PostMessageBus` is used by JavaScript applications to communicate between a WebWorker and the UI.
2. The `IsolateMessageBus` is used by Dart applications to communicate between a background Isolate and the UI.
Angular also includes three experimental MessageBus implementations:
1. The `WebSocketMessageBus` is a Dart MessageBus that lives on the UI and communicates with an angular
application running on a server. It's intended to be used with either the `SingleClientServerMessageBus` or the
`MultiClientServerMessageBus`.
2. The `SingleClientServerMessageBus` is a Dart MessageBus that lives on a Dart Server. It allows an angular
application to run on a server and communicate with a single browser that's running the `WebSocketMessageBus`.
3. The `MultiClientServerMessageBus` is like the `SingleClientServerMessageBus` except it allows an arbitrary
number of clients to connect to the server. It keeps all connected browsers in sync and if an event fires in
any connected browser it propagates the result to all connected clients. This can be especially useful as a
debugging tool, by allowing you to connect multiple browsers / devices to the same angular application,
change the state of that application, and ensure that all the clients render the view correctly. Using these tools
can make it easy to catch tricky browser compatibility issues.
### Using the MessageBus in Your Application
**Note**: If you want to pass custom messages between the UI and WebWorker, it's recommended you use the
[MessageBroker](#using-the-messagebroker-in-your-application). However, if you want to control the messaging
protocol yourself you can use the MessageBus directly.
You can obtain the MessageBus on both the render and worker thread through DI.
To use the MessageBus you need to initialize a new channel on both the UI and WebWorker.
In TypeScript that would look like this:
```TypeScript
// index.ts, which is running on the UI.
import {WORKER_RENDER_PLATFORM, WORKER_RENDER_APPLICATION, WORKER_SCRIPT, MessageBus} from "angular2/platform/worker_render";
import {platform} from "angular2/core";
let appRef = platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION, new Provider(WORKER_SCRIPT, {useValue: "loader.js"});
let bus = appRef.injector.get(MessageBus);
bus.initChannel("My Custom Channel");
```
```TypeScript
// background_index.ts, which is running on the WebWorker
import {MessageBus} from 'angular2/platform/worker_app';
@Component({...})
@View({...})
export class MyComponent {
constructor (bus: MessageBus) {
bus.initChannel("My Custom Channel");
}
}
```
Once the channel has been initialized either side can use the `from` and `to` methods on the MessageBus to send
and receive messages. Both methods return EventEmitter. Expanding on the example from earlier:
```TypeScript
// index.ts, which is running on the UI.
import {WORKER_RENDER_PLATFORM, WORKER_RENDER_APPLICATION, WORKER_SCRIPT, MessageBus} from "angular2/platform/worker_render";
import {platform} from "angular2/core";
let appRef = platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION, new Provider(WORKER_SCRIPT, {useValue: "loader.js"});
let bus = appRef.injector.get(MessageBus);
bus.initChannel("My Custom Channel");
bus.to("My Custom Channel").emit("Hello from the UI");
```
```TypeScript
// background_index.ts, which is running on the WebWorker
import {Component, View} from 'angular2/core';
import {MessageBus} from 'angular2/platform/worker_app';
@Component({...})
@View({...})
export class MyComponent {
constructor (bus: MessageBus) {
bus.initChannel("My Custom Channel");
bus.from("My Custom Channel").observer((message) => {
console.log(message); // will print "hello from the UI"
});
}
}
```
This example is nearly identical in Dart, and is included below for reference:
```Dart
// index.dart, which is running on the UI.
import 'package:angular2/web_workers/ui.dart';
main() {
import "angular2/core.dart";
import "angular2/platform/worker_render.dart";
platform([WORKER_RENDER_PLATFORM])
.asyncApplication(initIsolate("my_worker.dart")).then((ref) {
var bus = ref.injector.get(MessageBus);
bus.initChannel("My Custom Channel");
bus.to("My Custom Channel").add("hello from the UI");
});
}
```
```Dart
// background_index.dart, which is running on the WebWorker
import 'package:angular2/platform/worker_app.dart';
@Component(...)
@View(...)
class MyComponent {
MyComponent (MessageBus bus) {
bus.initChannel("My Custom Channel");
bus.from("My Custom Channel").listen((message) {
print(message); // will print "hello from the UI"
});
}
}
```
The only substantial difference between these APIs in Dart and TypeScript is the different APIs for the
`EventEmitter`.
**Note:** Because the messages passed through the MessageBus cross a WebWorker boundary, they must be serializable.
If you use the MessageBus directly, you are responsible for serializing your messages.
In JavaScript / TypeScript this means they must be serializable via JavaScript's
[structured cloning algorithim](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm).
In Dart this means they must be valid messages that can be passed through a
[SendPort](https://api.dartlang.org/1.12.1/dart-isolate/SendPort/send.html).
### MessageBus and Zones
The MessageBus API includes support for [zones](http://www.github.com/angular/zone.js).
A MessageBus can be attached to a specific zone (by calling `attachToZone`). Then specific channels can be
specified to run in the zone when they are initialized.
If a channel is running in the zone, that means that any events emitted from that channel will be executed within
the given zone. For example, by default angular runs the EventDispatch channel inside the angular zone. That means
when an event is fired from the DOM and received on the WebWorker the event handler automatically runs inside the
angular zone. This is desired because after the event handler exits we want to exit the zone so that we trigger
change detection. Generally, you want your channels to run inside the zone unless you have a good reason for why
they need to run outside the zone.
### Implementing and Using a Custom MessageBus
**Note:** Implementing and using a Custom MessageBus is experimental and the APIs may change.
If you want to drive your application from something other than a WebWorker you can implement a custom message
bus. Implementing a custom message bus just means creating a class that fulfills the API specified by the
abstract MessageBus class.
If you're implementing your MessageBus in Dart you can extend the `GenericMessageBus` class included in angular.
if you do this, you don't need to implement zone or channel support yourself. You only need to implement a
`MessageBusSink` that extends `GenericMessageBusSink` and a `MessageBusSource` that extends
`GenericMessageBusSource`. The `MessageBusSink` must override the `sendMessages` method. This method is
given a list of serialized messages that it is required to send through the sink.
The `MessageBusSource` needs to provide a [Stream](https://api.dartlang.org/1.12.1/dart-async/Stream-class.html)
of incoming messages (either by passing the stream to `GenericMessageBusSource's` constructor or by calling
attachTo() with the stream). It also needs to override the abstract `decodeMessages` method. This method is
given a List of serialized messages received by the source and should perform any decoding work that needs to be
done before the application can read the messages.
For example, if your MessageBus sends and receives JSON data you would do the following:
```Dart
import 'package:angular2/src/web_workers/shared/generic_message_bus.dart';
import 'dart:convert';
class JsonMessageBusSink extends GenericMessageBusSink {
@override
void sendMessages(List<dynamic> messages) {
String encodedMessages = JSON.encode(messages);
// Send encodedMessages here
}
}
class JsonMessageBusSource extends GenericMessageBuSource {
JsonMessageBusSource(Stream incomingMessages) : super (incomingMessages);
@override
List<dynamic> decodeMessages(dynamic messages) {
return JSON.decode(messages);
}
}
```
Once you've implemented your custom MessageBus in either TypeScript or Dart, you must provide it through DI
during bootstrap like so:
In TypeScript:
```TypeScript
// index.ts, running on the UI side
import {platform, Provider, APP_INITIALIZER, Injector} from 'angular2/core';
import {
WORKER_RENDER_PLATFORM,
WORKER_RENDER_APPLICATION_COMMON,
initializeGenericWorkerRenderer,
MessageBus
} from 'angular2/platform/worker_render';
var bus = new MyAwesomeMessageBus();
platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION_COMMON, new Provider(MessageBus, {useValue: bus}),
new Provider(APP_INITIALIZER, {
useFactory: (injector) => () => initializeGenericWorkerRenderer(injector),
deps: [Injector],
multi: true
})
]);
```
```TypeScript
// background_index.ts, running on the application side
import {WORKER_APP_PLATFORM, genericWorkerAppProviders} from "angular2/platform/worker_app";
import {NgZone, platform, Provider} from "angular/core";
import {MyApp} from './app';
/**
* Do initialization work here to set up the app thread and MessageBus;
* Once you have a working MessageBus you should bootstrap your app.
*/
platform([WORKER_APP_PLATFORM_PROVIDERS])
.application([WORKER_APP_APPLICATION_COMMON, new Provider(MessageBus, {useValue: bus}),
new Provider(APP_INITIALIZER, {useFactory: (zone, bus) => () => initAppThread(zone, bus), multi: true, deps: [NgZone, MessageBus]})])
.bootstrap(MyApp);
function initAppThread(zone: NgZone, bus: MyAwesomeMessageBus): void{
/**
* Here you can do any initilization work that requires the app providers to be initialized.
* At a minimum, you must attach your bus to the zone and setup a DOM adapter.
* Depending on your environment you may choose to do more work here.
*/
}
```
In Dart:
```Dart
// index.dart, running on the UI side
import 'package:angular2/core.dart';
import 'package:angular2/platform/worker_render.dart';
main() {
var bus = new MyAwesomeMessageBus();
platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION_COMMON, new Provider(MessageBus, useValue: bus),
new Provider(APP_INITIALIZER,
useFactory: (injector) => () => initializeGenericWorkerRenderer(injector),
deps: [Injector],
multi: true
)
]);
}
```
```Dart
// background_index.dart, running on the application side
import "package:angular2/platform/worker_app.dart";
import "package:angular2/core.dart";
import "./app.dart" show MyApp;
main() {
/**
* Do initialization work here to set up the app thread and MessageBus;
* Once you have a working MessageBus you should bootstrap your app.
*/
reflector.reflectionCapabilities = new ReflectionCapabilities();
platform([WORKER_APP_PLATFORM_PROVIDERS])
.application([WORKER_APP_APPLICATION_COMMON, new Provider(MessageBus, useValue: bus),
new Provider(APP_INITIALIZER, useFactory: (zone, bus) => () => initAppThread(zone, bus), multi: true, deps: [NgZone, MessageBus])])
.bootstrap(MyApp);
}
void initAppThread(NgZone zone) {
/**
* Here you can do any initilization work that requires the app providers to be initialized.
* At a minimum, you must attach your bus to the zone and setup a DOM adapter.
* Depending on your environment you may choose to do more work here.
*/
}
```
Notice how we use the `WORKER_RENDER_APPLICTION_COMMON` providers instead of the `WORKER_RENDER_APPLICATION` providers on the render thread.
This is because the `WORKER_RENDER_APPLICATION` providers include an application initializer that starts a new WebWorker/Isolate.
The `WORKER_RENDER_APPLICATION_COMMON` providers make no assumption about where your application code lives.
However, we now need to provide our own app initializer. At the very least this initializer needs to call `initializeGenericWorkerRenderer`.
## MessageBroker
The MessageBroker is a higher level messaging abstraction that sits on top of the MessageBus. It is used when you
want to execute code on the other side of a runtime boundary and may want to receive the result.
There are two types of MessageBrokers:
1. The `ServiceMessageBroker` is used by the side that actually performs
an operation and may return a result;
2. The `ClientMessageBroker` is used by the side that requests that
an operation be performed and may want to receive the result.
### Using the MessageBroker In Your Application
To use MessageBrokers in your application you must initialize both a `ClientMessageBroker` and a
`ServiceMessageBroker` on the same channel. You can then register methods with the `ServiceMessageBroker` and
instruct the `ClientMessageBroker` to run those methods. Below is a lightweight example of using
MessageBrokers in an application. For a more complete example, check out the `WebWorkerRenderer` and
`MessageBasedRenderer` inside the Angular WebWorker code.
#### Using the MessageBroker in TypeScript
```TypeScript
// index.ts, which is running on the UI with a method that we want to expose to a WebWorker
import {WORKER_RENDER_PLATFORM, WORKER_RENDER_APPLICATION, WORKER_SCRIPT, ServiceMessageBrokerFactory} from "angular2/platform/worker_render";
import {platform} from "angular2/core";
let appRef = platform([WORKER_RENDER_PLATFORM])
.application([WORKER_RENDER_APPLICATION, new Provider(WORKER_SCRIPT, {useValue: "loader.js"});
let injector = instance.injector;
var broker = injector.get(ServiceMessageBrokerFactory).createMessageBroker("My Broker Channel");
// assume we have some function doCoolThings that takes a string argument and returns a Promise<string>
broker.registerMethod("awesomeMethod", [PRIMITIVE], (arg1: string) => doCoolThing(arg1), PRIMITIVE);
```
```TypeScript
// background.ts, which is running on a WebWorker and wants to execute a method on the UI
import {Component, View} from 'angular2/core';
import {ClientMessageBrokerFactory, PRIMITIVE, UiArguments, FnArgs} from 'angular2/platform/worker_app';
@Component(...)
@View(...)
export class MyComponent {
constructor(brokerFactory: ClientMessageBrokerFactory) {
var broker = brokerFactory.createMessageBroker("My Broker Channel");
var arguments = [new FnArg(value, PRIMITIVE)];
var methodInfo = new UiArguments("awesomeMethod", arguments);
broker.runOnService(methodInfo, PRIMTIVE).then((result: string) => {
// result will be equal to the return value of doCoolThing(value) that ran on the UI.
});
}
}
```
#### Using the MessageBroker in Dart
```Dart
// index.dart, which is running on the UI with a method that we want to expose to a WebWorker
import "angular2/core.dart";
import "angular2/platform/worker_render.dart";
main() {
platform([WORKER_RENDER_PLATFORM])
.asyncApplication(initIsolate("my_worker.dart")).then((ref) {
var broker = ref.injector.get(ServiceMessageBrokerFactory).createMessageBroker("My Broker Channel");
// assume we have some function doCoolThings that takes a String argument and returns a Future<String>
broker.registerMethod("awesomeMethod", [PRIMITIVE], (String arg1) => doCoolThing(arg1), PRIMITIVE);
});
}
```
```Dart
// background.dart, which is running on a WebWorker and wants to execute a method on the UI
import 'package:angular2/core.dart';
import 'package:angular2/platform/worker_app.dart';
@Component(...)
@View(...)
class MyComponent {
MyComponent(ClientMessageBrokerFactory brokerFactory) {
var broker = brokerFactory.createMessageBroker("My Broker Channel");
var arguments = [new FnArg(value, PRIMITIVE)];
var methodInfo = new UiArguments("awesomeMethod", arguments);
broker.runOnService(methodInfo, PRIMTIVE).then((String result) {
// result will be equal to the return value of doCoolThing(value) that ran on the UI.
});
}
}
```
Both the client and the service create new MessageBrokers and attach them to the same channel.
The service then calls `registerMethod` to register the method that it wants to listen to. Register method takes
four arguments. The first is the name of the method, the second is the Types of that method's parameters, the
third is the method itself, and the fourth (which is optional) is the return Type of that method.
The MessageBroker handles serializing / deserializing your parameters and return types using angular's serializer.
However, at the moment the serializer only knows how to serialize angular classes like those used by the Renderer.
If you're passing anything other than those types around in your application you can handle serialization yourself
and then use the `PRIMITIVE` type to tell the MessageBroker to avoid serializing your data.
The last thing that happens is that the client calls `runOnService` with the name of the method it wants to run,
a list of that method's arguments and their types, and (optionally) the expected return type.