feature: ngHost (reverse host projection)

[mhevery]

At times it is desirable to be able to wrap a host element into a template. (We may refer to it as host projection, to be consistent with content projection)

The idea is that we would allow the component's view to declare <ng-host> which would project the host element in similar fashion to the <ng-content> projection

Imagine we have template:

<menu>
  <menu-item>A</menu-item>
  <menu-item>B</menu-item>
</menu>

and we want

<menu>
  <ul>
    <li><menu-item>A</menu-item></li>
    <li><menu-item>B</menu-item></li>
  </ul>
</menue>

Here the <menu> can have <ul>, but how do we wrap <menu-item> in <li>?

@Component({
  selector: 'menu-item',
  template: '<li><ng-host></ng-host></li>'
}) 
class MenuItem {...}

Notes:

• <ng-host> could have optional attribute to suppress the host element, this way it will be <li>A</li> (remove <menu-item>)

/cc @jelbourn @tbosch @pkozlowski-opensource

[jelbourn]

@hansl originally filed this in #7297

[pkozlowski-opensource]

I think that this issue / proposal captures @jelbourn need as previously described in #7297

What I'm after is something different - I would like to be able to wrap <menu-item> children in the <menu> template. In other words, the <li> from the example should be part of the <menu> template, not the <menu-item> one.

Ideally I should be able to query <menu-item> children from the JS side (@ContentChildren), do some processing on a queried set (ex. take only 5 first items) and then wrap each individual item in the <menu>s template.

[pkozlowski-opensource]

The legitimate question here would be: why do I want to have <li> in the <menu> template instead of the <menu-item>?

To start, if we assume that <li> belongs to <menu-item> I could do things as of today like so:

@Component({
  selector: 'menu-item',
  template: '<li><ng-content></ng-content></li>'
}) 
class MenuItem {...}

In other words <ng-host> wouldn't buy me anything here, would it?

But the main reason to move <li> on the <menu> level is flexibility. If I can have it on the <menu> level I can then create variants of the <menu> without touching <menu-item> implementation. In this sense <menu-item> would act as a directive that captures inputs and content, but it is <menu> that would do all the heavy-lifting.

The other reason is that I would like to be able to process (ex.: filter, get only 5 first ones) children on the JS side and then insert them in the <menu> template.

[tbosch]

Pawel,
if you want to do this kind of filtering and wrapping,
you need to use a <template> element. ng-content is a compile time
construct and can't be controlled during runtime, and I would like to keep
it this way as that makes it fast.

We can debate a nicer syntax for writing <template> though, e.g. allow a
directive to define that an element should be treated as <template> as
well.

On Fri, Mar 11, 2016 at 6:36 AM Pawel Kozlowski notifications@github.com
wrote:

The legitimate question here would be: why do I want to have

in the

template instead of the ?

To start, if we assume that

belongs to I could do things
as of today like so:

@component({
selector: 'menu-item',
template: '

'
}) class MenuItem {...}

In other words wouldn't buy me anything here, would it?

But the main reason to move

on the level is flexibility. If I
can have it on the level I can then create variants of the
without touching implementation. In this sense
would act as a directive that captures inputs and content, but it is

that would do all the heavy-lifting.

The other reason is that I would like to be able to process (ex.: filter,
get only 5 first ones) children on the JS side and then insert them in the

template.

—
Reply to this email directly or view it on GitHub
feature: ngHost (reverse host projection) #7546 (comment).

[jelbourn]

@pkozlowski-opensource the Portal code we have in material2 might help; we're currently planning on using it to build our tabs.
https://github.com/angular/material2/tree/master/src/core/portal

[pkozlowski-opensource]

@tbosch thnx for getting back on this one. I'm going to experiment today with having <menu-item> as a template directive, although I'm not sure it solves the problem: I've got another use case where I believe that we should be able to "manually" project children previously queried from JS. Let me put it in a doc and dig into your template-based proposal as well.

I'm not suggesting that we need to change how <ng-conent> works - for me it is perfectly fine if it stays a compile-time, super-fast constructs that covers the most common use-cases. What I'm saying is that we might need something new / alternative which is more flexible, potentially slower (and probably imperative in nature) but still in our arsenal for cases that are more tricky.

We can debate a nicer syntax for writing <template> though, e.g. allow a
directive to define that an element should be treated as <template> as
well.

Exactly. Even if we can take template-based approach it would result in the usage similar to:

<menu>
    <template>
       <menu-item>A</menu-item>
    </template>
    <template>
       <menu-item>B</menu-item>
    </template>
</menu>

which makes sense from the implementation / framework's internal structures point of view, but is not user-friendly.

[pkozlowski-opensource]

@tbosch OK, so I've spent some more time digging into the topic and experimenting with template elements. Indeed, using template elements I can move (in)famous <li>s into <menu>'s template. The downside of this is that now <menu-item> now needs to be a template directive so a user would have to write:

<menu>
    <template menu-item>A<template>
    <template menu-item>B<template>
</menu>

which is not as "nice" as compared to:

<menu>
  <menu-item>A</menu-item>
  <menu-item>B</menu-item>
</menu>

But I guess this is where your proposal comes in:

We can debate a nicer syntax for writing <template> though, e.g. allow a
directive to define that an element should be treated as <template> as
well.

Indeed if we could somehow express that <menu-item>A<menu-item> is the same (from the compiler's point of view) as <template menu-item>A<template> we would be all set!

As soon as capturing of TemplateRefs is sorted out then there is one more mechanism needed: ability to insert captured template refs. I can do it easily from code (viewContainerRef.createEmbeddedView(tplRef)) but it I would need a way of inserting things from a template point of view (equivalent of the <insert-tpl> from my implementation attempt: http://plnkr.co/edit/sleVVrgqo66JN9G48yyj?p=preview)

[todoubaba]

Another variation

<menu>
 <li *menu-item>A</li>
 <li *menu-item>B</li>
 <li *menu-item>C</li>
</menu>

http://plnkr.co/edit/oxnS6pMj95YpyNgOvdab?p=preview

[tbosch]

Closing this issue in favor of #7297. @pkozlowski-opensource please create separate issues for your aspects to it.

[pkozlowski-opensource]

Just had a very productive chat with @tbosch and we've decided to close this issue in favor of 2 new, more specific ones:

• capturing TemplateRef - going to create an issue for this
• inserting TemplateRefs - [feature] A directive to insert / stamp out TemplateRefs #7615

[jelbourn]

@pkozlowski-opensource I think the first issue might be #7158

[pkozlowski-opensource]

@jelbourn #7158 covers some aspects of it, yes. But there is something else I'm after as well. Basically it would allow users write <menu-item>some content</menu-item> instead of <template menu-item>some content<template>.

But yeh, we are touching upon related topics.