templating engine drops attributes from au-compose tag

[Dmitry Arkhipov]

🐛 Bug Report

When using au-compose with additional html attributes (like style for example) in template - they are dropped in output HTML.
It worked in earlier versions.

Repro link https://stackblitz.com/edit/au2-conventions-peynua?file=src%2Fmy-app.html,src%2Fmy-app.ts,src%2Fmy-app.css

🤔 Expected Behavior

output html is like this:

<au-compose style="width: 20%"></au-compose>
<au-compose style="width: 30%"></au-compose>

😯 Current Behavior

output html is like this:

<au-compose></au-compose>
<au-compose></au-compose>

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Aurelia	2.0.0-beta.8
Language
Browser
Bundler
Operating System
NPM/Node/Yarn

[bigopon]

Thanks @ekzobrain , the style attribute should also be transferred to the host element of the composed custom element. This current behavior is unintentional and missed in the previous PR.

Edit: I thought I missed it but I didn't. Its transferring the attribute in case of custom element composition. What's reported above was for the case of non-custom element as component/view-model composition.

[Dmitry Arkhipov]

Yes, in case of rendering a custom element - it works. But does not work with containerless feature (in this case i think attributes should remain on au-compose, as with non-custom element composition).
au-compose also seems not to work with non-custom element at all. Nothing gets renderer in this case.

[bigopon]

non-custom element at all. Nothing gets renderer in this case.

Non custom elements don't get the same treatment with custom elements, so the static template part wasn't used. Were you expecting it to work as if it was a custom element?

attributes should remain on au-compose, as with non-custom element composition

We could, but this will make it incredibly complex I think. Shouldn't it be simpler for apps to have

<au-compose containerless ...>

?

[Dmitry Arkhipov]

I think you need an RFC about dynamic composition behavior, which will be transferred to docs afterwards :) The first thing to note is that all dynamic composition parts (au-compose, dialog, au-viewport) should work the same regarding:

1. explicit custom elements / custom elements with convensions / non-custom elements / etc (in fact I do not know exact differences between those)
2. containerless support
3. attribute transferring support

This issue is also relative #1695

I would try to extract a general dynamic composition function to the core, and then reuse it where applicable. This will result in:

1. more reliable code
2. more convenient overall behavior
3. less code
4. better framework extension capaibilities for plugin authors

About containerless - I suspect that it is better to use the containerless option of a composed custom element, while only element itself knowns it's capabilities to work without the host. But if it is hard to detect this while transferring attributes, then it should be pointed out by RFC. This could be solved by another option au-compose option which will allow to switch off attribute transferring at all.

[bigopon]

I would try to extract a general dynamic composition function to the core,

It likely will be like this, thanks for the suggestion. At the moment, the primitives they are sharing are the same, but maybe there could be a slightly higher level API set for this.

But if it is hard to detect this while transferring attributes

It's not hard to transfer, but it's unclear what happens when we transition from a containerless to a non-containerless custom element. All bindings that resulted in attributes on <au-compose> elements will need to be dealt with, or left alone? For example, in your code of this issue, what happens when we compose another element that is not containerless afterwards. But yeah, maybe an RFC is better so that the behaviors can be properly doc'd.