Add support for attribute lookup for multi slot transclusion

[david2tm]

Currently ti use multi slot transfusion, we need to name our elements using not standard HTML elements. Like in a snippet below.

<!-- parent.html -->
<div data-my-directive>
  <my-slot>
    <span>Lorem Ipsum</span>
  </my-slot>
</div>

This is not HTML5 compliant.
Enabling attribute lookup, may help this. Consider following syntax:

<!-- parent.html -->
<div data-my-directive>
  <div data-my-slot>
    <span>Lorem Ipsum</span>
  </div>
</div>

[Narretz]

This is not HTML5 compliant.

I assume you are using a validator or such?
Because the w3c has a spec for custom elements, and while that may not be 100% HTML5 compliant, it's definitely here to stay: http://w3c.github.io/webcomponents/spec/custom/

[Narretz]

/cc @petebacondarwin

[petebacondarwin]

I agree with @Narretz. See http://stackoverflow.com/a/9845124/287070
Is using custom-elements breaking your application in some way?

[david2tm]

It was a decision we made about two years ago, to be fully compliant, meaning the use of data-* prefix instead of element names, etc.
I had a discussion with a team, and we decided to allow non standard (custom) elements, so as of now it is no longer an issue for us.

After saying that, since most directives (or should I say features) in Angular do provide an ability to be used as attributes instead of elements, it seems only logical to me, that slots will allow this too.

[petebacondarwin]

@david2tm thanks for following up on this. The main reasons for the decision was simplicity and performance.

• It is much faster only to check the names of the top level elements of the template for matching slots.
• The code is simpler to understand and maintain

That being said, we were also conscious that this decision did not preclude us from making the matching more sophisticated later (such as jquery style selectors), whereas backing down from an overly sophisticated public API design is much harder.

So far you are the only person to have requested the more sophisticated API. If there are other people out there who would like to see it, then please say so and we can reconsider.

Given that this is no longer a problem for you I am going to close this issue.

[johngull]

Hello,

I faced problem when attribute lookup will help much.
It appears that when you add in transclude slot and tags browser remove it, because there is no table around.
So when you append it to the table inside template you got just a 'text1\ntext2' instead of text1text2

I beleive that with the attribute lookup this can be fixed.

If you have another workaround please share it.

Thank you.

[cheapsteak]

This does not seem to work with tables

component('myTable', {
    transclude: {
      row: 'row',
    },
    replace: true,
    template: `
      <table>
        <tr ng-repeat="row in vm.rows" ng-transclude="row">
        </tr>
      </table>
    `,
  })

<my-table>
    <row>
        <td>this doesn't show up</td>
    </row>
</my-table>

The "" tag ends up being rendered inside the <tr>, and <td>s are lost

[petebacondarwin]

I wonder if this is because the ngRepeat is creating its own transclusions?
Could you create a new bug for this?

[morewry]

I don't know when the Angular team made the call to use this element directivey thing instead of giving the ability to specify a selector, but I'm unhappy about it. I assure you 100% this issue was not filed by the only person to have requested it. Maybe in these words, but not limiting to elements was part of the design Kara and I did, the presentations we gave (which you could and should have referenced when building this feature), and in the original PR she created to add multi-transclusion (the one that was closed and later rewritten). It was emulating Shadow DOM v0 at the time. Being able to specify a selector (/ use an attribute, to a lesser but perhaps still worthwhile degree) would have allowed authors to support the same interface for a multi-transclude Angular directive as for a Custom Element with Shadow DOM v0 or v1.

I've just run into a use case that's caused me to dig into the version of this that got shipped in Angular and it got completely in my way. To find a related issue where a the core team claimed this was news / wasn't asked for is just mind-boggling. The only way it could have been news to anyone would be if they completely ignored standards, prior art in the community, and prior PRs addressing this use case while implementing.

Kind of a let down. But, you know, if it's this hard for a framework that is much closer to the web dev community to do a feature like this and successfully integrate all that background into it, it puts into perspective how much web standards historically struggled with that.

[petebacondarwin]

Hi @morewry!

Great to hear from you after all this time. I remember watching your talk with @kara about this feature. It was a really great piece of coding and presentation.

When we came to implement this, we made had to make some trade offs for performance and complexity. You can see that we debated lots of this at the time:

• feat(ngTranscludeSelect): add ng-transclude-select directive for multi-transclusion #11736 (comment)
• WIP - DO NOT MERGE - feat($compile): multiple transclusion via slots #12742
• feat($compile): multiple transclusion via named slots #12934

This debate also included @kara in the process. I am not sure why you were not involved? I guess you were not aware of the development, in which case I am sorry.

The aim of the final design was a subset of the kind of features that you are looking for here. This would allow us to put out a performant feature that dealt with the majority of the use cases, while giving us the option of adding more functionality if it was needed.

It might well be true that there are lots of developers out there who desired these extra features, but we can only go on the direct feedback we get via issues opened. The fact is that, in the 3 years since we merged the final implementation, we have had only 3 developers (not including you) who have asked about this: the first one specifically said that they worked around it and no longer needed it; the second never followed up on their comment; the third created a new issue but it was closed after a discussion as invalid.

We were always open to the idea of extending the functionality but I fear that you have been bitten by the problem too late. Unfortunately we are now some way in to the LTS period for the AngularJS project, which means that new features like this are very unlikely to be added.

It is possible you could workaround this problem by using an external approach, similar to what you developed originally or something like #12934 (comment) developed by @fenduru.

[morewry]

Oh, I never doubted there were reasons! Nor that I could rewrite my own, but in hindsight it still seems a shame that parity for the end game of compatibile component interfaces wasn't prioritized to the extent I would have liked. Thanks for sharing the context and a potential work around. Unfortunately, given my own need to make trade-offs, I'll probably just have to paper over it with a convention.

It's increasingly interesting to me how features evolve and how much being in at least the right virtual place at the right time impacts it. Understandably, but perhaps not ideally. How much do you give what people specifically ask for? Versus how much do you read between the lines and guess what people might ask if they had the context?

It reminds me of the last role I had that involved customer support. I gained a first-hand feel for how many bugs and limitations our product had through what kind of requests and complaints were made. I learned the same customers tended to contact us again and again, while the majority didn't. And when it came time for new development, we rarely addressed those issues that were fundamental and persistent. I internalized at some point that most people with an issue just work around it without saying a word. But also that in the big picture, those issues could be just as important as the more dramatic ones.

This certainly may not be one of those times, but I'm okay with being wrong with good intentions. So I still think given Angular 1 is on its way out, enabling strategic non-breaking migrations would have been worthwhile. (But I get compromises, so this is mostly thinking out loud about and theoretically rather than an actionable request. What can you do, really, but make what seems to be the best call under the circumstances.)