Validate transclusions

[MichaelRFairhurst]

Obviously a lot that could be done here, but it would be a good idea to validate the selectors where the directive is defined, and validate that all of those selectors are satisfied exactly once when the directive with transclusion is later used (will have to investigate the rules here to make sure we validate it correctly)

[zoechi]

What do you mean with "exactly once"?

I think that when more than one element matches all should go to the matching <ng-content>.

If elements match more than one <ng-content>s selector they should go into the first one.
The elements not matching any selector should go into a <ng-content> without a selector (if such an <ng-content> exists.

At least this is how it is with custom elements (Polymer) and I guess also currently in Angular2.

There are also use cases where child elements intentionally don't match any selector, even when there is no <ng-content> without a selector. Not everything passed to a parent needs to be displayed, it could only to allow the parent to get a reference using @ContentChild().

I think it would be great to have a way to specify on the parent what is expected to be passed by the child.

[MichaelRFairhurst]

Interesting, didn't realize this was used in such a loose way. I like your idea of making the contract more specific.

By exactly once I meant that no two elements should match a single ng-content selector. But if that's valid, then I take it back.

In terms of content that's never used in the transclusion, we should be able to check both <ng-content> and @ContentChild, though more and more I'm seeing that I should have just made a ticket to research what types of errors we could report in the presence of transclusion, because its getting a bit dicey.

At the very least, without dealing in what's feasible or how it could be done, it would be nice if we could catch

• misspellings that interfere with transclusion
• specifying something bogus for transclusion
• missing something important for transclusion
• refactoring errors when transclusion selectors change (since this will be in the analyzer)

and maybe some more (transcluding something twice is arguably its own item).

Although, maybe just as well or better is to autocomplete matching DOM for the available transclusions, which would be a really cool feature, and let tests could cover those failure cases.

[zoechi]

refactoring errors when transclusion selectors change (since this will be in the analyzer)

Any support here would be fantastic

A common error with <ng-content> is

<div *ngFor="let x of y">
  <ng-content selector="foo"></ng-content>
</div>

I think catching this would be great for many starting with Angular2 that try to use <ng-content> this way.

I guess we just need to come up with a list of concrete error cases that can be clearly identified as such by analyzing the code.

[MichaelRFairhurst]

Upping the priority here, this causes a false error when:

   <ng-content selector="element-selector">

and then when this ng-content is provided by the child, its flagged as an unknown tag.

   <my-comp>
     <element-selector>...</element-selector>
   </my-comp>

[MichaelRFairhurst]

Going to keep this as a master ticket and create some subtickets to track various pieces we could validate here

[MichaelRFairhurst]

Reducing the priority on this again. I think the false error is not a first class use case, in fact, its
arguably a discourageable pattern.

[MichaelRFairhurst]

This is done, forever ago in #230