Skip to content

Commit cd953ce

Browse files
joshkurzmhevery
authored andcommitted
docs(core): update core directives document
Signed-off-by: Josh Kurz <jkurz25@gmail.com>
1 parent 726fecb commit cd953ce

1 file changed

Lines changed: 64 additions & 6 deletions

File tree

modules/angular2/docs/core/02_directives.md

Lines changed: 64 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -213,7 +213,7 @@ Dependency Injection (DI) is a key aspect of directives. DI allows directives to
213213

214214
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.
215215

216-
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hierarchy and if not found using the application level injector.
216+
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.
217217

218218
To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
219219

@@ -260,17 +260,17 @@ Assume the following DOM structure for `my_app.html`:
260260

261261
### Injecting other Directives
262262

263-
Injecting other directives into directives follows a similar mechanism as injecting services, but with added constraint of visibility governed by DOM structure.
263+
Injecting other directives into directives follows a similar mechanism as injecting services into directives, but with added constraint of visibility governed by DOM structure.
264264

265265
There are five kinds of visibilities:
266266

267267
* (no annotation): Inject dependant directives only if they are on the current element.
268268
* `@ancestor`: Inject a directive if it is at any element above the current element.
269-
* `@parent`: Inject a directive which is direct parent of the current element.
269+
* `@parent`: Inject a directive which is a direct parent of the current element.
270270
* `@child`: Inject a list of direct children which match a given type. (Used with `Query`)
271271
* `@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
272272

273-
NOTE: if the injection constraint can not be satisfied by the current visibility constraint, then it is forward to the normal injector which may provide a default value for the directive or it may throw an error.
273+
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.
274274

275275
Here is an example of the kinds of injections which can be achieved:
276276

@@ -327,12 +327,70 @@ Assume the following DOM structure for `my_app.html`:
327327
</form> |
328328
```
329329

330+
#### Shadow DOM effects on Directive DI
330331

331-
### Shadow DOM effects on Dependency Injection
332+
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, declaritively specify the required component as an injectable.
332333

333-
Shadow DOM provides an encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundaries.
334+
```
335+
@Component({
336+
selector: '[kid]',
337+
injectables: []
338+
})
339+
@View({
340+
templateUrl: 'kid.html',
341+
directives: []
342+
})
343+
class Kid {
344+
constructor(
345+
@Parent() dad:Dad,
346+
@Optional() grandpa:Grandpa
347+
) {
348+
this.name = 'Billy';
349+
this.dad = dad.name;
350+
this.grandpa = grandpa.name;
351+
}
352+
}
334353
354+
@Component({
355+
selector: '[dad]',
356+
injectables: [Grandpa]
357+
})
358+
@View({
359+
templateUrl: 'dad.html',
360+
directives: [Kid]
361+
})
362+
class Dad {
363+
constructor(@Parent() dad:Grandpa) {
364+
this.name = 'Joe Jr';
365+
this.dad = dad.name;
366+
console.log(dad)
367+
}
368+
}
335369
370+
@Component({
371+
selector: '[grandpa]',
372+
injectables: []
373+
})
374+
@View({
375+
templateUrl: 'grandpa.html',
376+
directives: [Dad]
377+
})
378+
class Grandpa {
379+
constructor() {
380+
this.name = 'Joe';
381+
}
382+
}
383+
```
384+
385+
Assume the following DOM structure for `grandpa.html`: The Dad has access to the Grandpa.
386+
```
387+
Name: {{name}}: <br> Children: <div dad></div>
388+
```
389+
390+
Assume the following DOM structure for `dad.html`: Here the rendered Kid will also have access to Grandpa.
391+
```
392+
Name: {{name}}: <br> Dad: {{dad}} <br> Children: <div kid></div>
393+
```
336394

337395
## Further Reading
338396

0 commit comments

Comments
 (0)