Issue 1:
I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Right now, there are two ways to get a component's "index":

Using *ngFor and getting the index from the context.

Using @ContentChildren or @ViewChildren on a parent component and moving the whatever logic uses the index to said parent component (only works when we are only interested in the index among components of the same class).

In cases where both of these are not possible, we have no way of getting a component's index. For instance, if you have a TemplateRef that contains several of your component statically:

<template>
<my-component>AAA<my-component>
<my-component>BBB<my-component>
<my-component>CCC<my-component>
</template>

The parents that could query for my-component are the ones from the original template's location, not the ones from where the template is instantiated.

Expected behavior

I do not know if it is possible, but I understand that each component has its own view, which is inserted inside a view container. Having access to the index of that view within its view container would be very useful.

If this is not possible for some reason, I'd be very interested in knowing why, so I can understand more about the structure of the runtime app.

Minimal reproduction of the problem with instructions

This is a feature request, nothing to reproduce.

What is the motivation / use case for changing the behavior?

Write "ordered" reusable components, or components that care about the number of siblings before them, that would work in any context (with or without *ngFor, inside a template embedded in another part of the app, ...).

Angular version: 2.4.X

Browser: all

Language: all

Issue 2:
Use Case

<ng-content> allows for static (compile time resolution) projection of content. There are cases where the projection needs to be controlled programmatically. A common example is when the parent component would like to wrap/decorate the child components during projection.

Mental Model

The mental model would be that <ng-content> is for fast static projection, but for dynamic projection one would use a query to get a hold of the child components in the form of ViewRefs which could then be inserted programmatically at any location in the tree.

Possible Solution

ContentViewRef extends ViewRef

@Content(selector) Provides a way to select direct children content elements using CSS selectors. (This would be after directives such as ngFor would unroll the content, and it would be in the correct order.)

This would allow selection of elements rather than directives. These ContentViewRefs could then be reinserted to any ViewContainerRef

We would need ngViewOutlet (similar to ngTemplateOutlet).

@Component({
template: `
<div *ngFor="let view of allViews">
<template ngViewOutlet="view"></template>
</div>
<ng-content><!-- project non selected nodes, such as text nodes --></ng-content>
`
})
class MySelect {
@Content('*') allViews: ContentViewRef[];

// another example
@Content('my-option') optionViews: ContentViewRef[];
}

@Component({
selector: 'app',
template: `
<my-select>
Option
<my-option>header</my-option>
<my-option *ngFor="let item in items">unrolled items {{item}}</my-option>
<my-option-group>
<my-option>
foo <b>bar</b>
<other-directive />
</my-option>
<my-separator></my-separator>
<my-option></my-option>
</my-option-group>
</my-select>
`
})
class App {}