templating engine drops attributes from au-compose tag
ekzobrain opened this issue Β· comments
π 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.
π€ 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 |
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.
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.
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 ...>
?
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:
- explicit custom elements / custom elements with convensions / non-custom elements / etc (in fact I do not know exact differences between those)
- containerless support
- 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:
- more reliable code
- more convenient overall behavior
- less code
- 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.
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.