You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/angular2/docs/core/02_directives.md
+64-6Lines changed: 64 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -213,7 +213,7 @@ Dependency Injection (DI) is a key aspect of directives. DI allows directives to
213
213
214
214
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.
215
215
216
-
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructorcan 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.
217
217
218
218
To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
219
219
@@ -260,17 +260,17 @@ Assume the following DOM structure for `my_app.html`:
260
260
261
261
### Injecting other Directives
262
262
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.
264
264
265
265
There are five kinds of visibilities:
266
266
267
267
* (no annotation): Inject dependant directives only if they are on the current element.
268
268
*`@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.
270
270
*`@child`: Inject a list of direct children which match a given type. (Used with `Query`)
271
271
*`@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
272
272
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.
274
274
275
275
Here is an example of the kinds of injections which can be achieved:
276
276
@@ -327,12 +327,70 @@ Assume the following DOM structure for `my_app.html`:
327
327
</form> |
328
328
```
329
329
330
+
#### Shadow DOM effects on Directive DI
330
331
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.
332
333
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
+
}
334
353
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
+
}
335
369
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.
0 commit comments