Make it possible to reason about content to project (content projection and content queries unification)

There are multiple use-cases where one would like to reason about content provided to a component (check if content was provided at all, count the number of items etc.).

To make the discussion more concrete let’s consider the following markup (full runnable scenario):

<my-container>
      <my-item></my-item>
      <my-item></my-item> 
      <my-item></my-item>
</my-container>

Given this markup the <my-container> component might want to answer the following questions:

• was content provided at all (existing, popular issue.: #26083)
• how many items were provided (as of today this could be done through content queries only).

On top of this the <my-container> implementation might want to do the following (all the provided examples boil down to the ability of projecting items individually):

• wrap each item into some markup;
• project only 2 first items;
• project every second item (or items in 2 separate columns);
• etc. etc.

Achieving any of the use-cases listed above is very difficult in the current Angular and it steams from the fact that one can’t reason (count, pick-up, check presence etc.) about individual items to project.

While content queries can be used, to some degree, to reason about content items individually, the content queries approach has its problems as well:

• we end up with 2 mechanism operating on content (content queries and content projection) - those 2 mechanism have different APIs, different capabilities, need to be learnt separately etc.;
• there is a fundamental mismatch between 2 mechanism: content projection operates on “blocks” that can’t be reason about (but capture content), while content queries are good with individual items but don’t capture content (we can’t insert result of a content query into the DOM).

This fundamental mismatch between content projection and content queries leads to many surprising situations and use-cases that can’t be implemented really. Again, here is a “typical” example: https://stackblitz.com/edit/angular-ivy-sumkgl?file=src%2Fapp%2Fapp.component.ts

In short: content projection and content queries are good mechanisms while used separately, but as soon as we try to use both mechanisms together we start to bump into serious problems.

The idea behind opening this issue is to capture use-cases that are difficult to implement and expose problems where both content queries and content projection are used together. This should open ways to designing a more powerful content projection where it is possible to reason about and project content with one API. To set expectations: there are no immediate implementation plans, we want to capture use-cases and experiment with different APIs first.

[bmtheo]

Here is one use case with the Angular Material lib : (ref for more info : https://github.com/angular/components/issues/9411)

The use case is to share some advanced form fields in an app (add features around a MatFormFieldControl) without reimplementing all the values of input

The content projection is used to project the input into the advanced form field The content queries are used by Angular Material to manipulate the input

Rough example :

<!-- my-advanced-field.component.html -->
<mat-form-field>
  <ng-content></ng-content>
  <!-- some other features of my advanced field -->
</mat-form-field>

<!-- my-component.component.html -->
<my-advanced-field>
  <input matInput ... > <!-- This is not possible today because it needs content projection and content queries -->
</my-advanced-field>

Full example here : https://stackblitz.com/edit/angular-material2-issue-jekywv

Without this, all the values of the input used by my-component needs to be implemented by my-advanced-field resulting in large boilerplate code

[MilesAl]

This “feature” should be implemented as soon as possible. There are some use cases that have this issue and the larger the application scales, the more issues arise. The mat-menu becomes partially unusable or requires a lot of redundant code, which is not acceptable for enterprise applications. Please work on this issue!