Aurelia: [RFC] au-host, au-bind, au-transfer-bindings, au-transfer-attrs, etc

[fkleuver]

Just some quick notes based on discussion on Discord, so we don't lose the conclusions/todos again.

• au-host
  Placed on any element inside the template of a containerless custom element.
  This element is then registered as the INode, Node, Element and HTMLElement to be injected into custom attributes that are placed on the containerless element on the outside.

Example:
app.html

<template>
  <my-element my-custom-attr></my-element>
</template>

my-element.html

<template>
  <div au-host>
    <!-- stuff -->
  </div>
</template>

my-custom-attr.ts

export class MyCustomAttr {
  constructor(el: Element) {
    // el is the HTMLDivElement that au-host was placed on
  }
}

• au-bind see https://github.com/aurelia/aurelia/issues/319

[brandonseydel]

Some proposals for transfer options/naming convention possibilities the au-host is pretty much on point @fkleuver ;)

<template>
<input au-accept="style" />
<input au-accept="class" />
<input au-accept />

</template>

<!-- Transfer All attributes and binding -->
<parent-element au-transfer style.bind="style" class="test"/> 
<!-- Transfer ONLY the style binding -->
<parent-element au-transfer="style" style.bind="style" class="test"/>
<!-- Transfer All attributes and binding with specific  -->
<parent-element au-transfer style.bind="style" class="test"/> 

[shahabganji]

Just my opinion around the idea:

<template>
    <my-element my-attr></my-element>
</template>

<template>
    <input au-host.accept="attr1, attr2" />
    <button au-host.only="attr3">Button</button>
</template>

maybe drop the au- prefix, just like bind, we could use host:

<template>
    <input host.accept="attr1, attr2" />
    <button host.only="attr3">Button</button>
</template>

See here in #319

[EisenbergEffect]

I agree with that. If we're going to need to use a .bind or other binding command with the attribute for normal use anyway, then we can drop the au- prefix since the attribute, in practice, has extremely low likelyhood of conflicting with any future web standard attribute or that of another library or framework.

[bigopon]

One question we probably need to answer early is do we want to support dynamic values.

Static is

<input host-transfer="value, min, max, type"/>

Dynamic is

<input host-transfer.bind="myAttrList">

[shahabganji]

IMO, I think they are even more important, the applications tend to be more dynamic, consider a custom input, we might need to bind the value property for that, transferring that binding to the inner input child without writing a whole bunch of repetitive code would be a huge benefit.

---

I am a little bit confused about the samples above:

Why do we need host-transfer attribute on the parent at all, because the intention of this should be to make things transparent and unobtrusive, the developer who used this custom element should not need to say which attributes to transfer, but the developer who maintained this component; the latter already listed the attributes in the design of the component via host.accept, host.except, and etc.

@bigopon Would you mind if I ask to elaborate more on that? And one more thing about naming, I like host.transfer as a name, sounds more consistent with other parts of Aurelia, I guess. :wink:

[bigopon]

@shahabganji the host-transfer in my example works in the same way with your host.accept, it's always an explicit list of options.
I think we may need some use cases here, I'll give it a try.

For host.accept, and host.except, how would it be if it's allowed to be dynamic? And a funny case: what if they are used together?

I'm leaning towards a static only option:

<material-field type="date" value.bind="value" min="01/01/1990" max="01/01/2100">

material-field.html:

<input host.accept="*" >
<input host.accept="type, value" >
<input host.accept="type, value, min, max" >

Like you see with host.accept="a bunch of attributes", it seems to be already enough for a list of attributes we want to (transfer / relay) on the <input/>

[shahabganji]

Sorry @bigopon for the late reply 🙏

Like you see with host.accept="a bunch of attributes", it seems to be already enough for a list of attributes we want to (transfer / relay) on the

I couldn't be agree more that only accept or transfer would be sufficient.

I am not sure I understand this part of your sentence correctly or not:

For host.accept, and host.except, how would it be if it's allowed to be dynamic? And a funny case: what if they are used together?

But I guess, you meant that only accept would be fine, LGTM too.

---

about using dynamic and static properties I give an example :

<search-bar value.bind="criteria" min="3" max="20" click.delegate="searchGoods()"></search-bar>

and the search-bar component:

<template>
    <input type="text" host.accept="min, max, value" />
    <button host.accept="click">Search</button>
</template>

Now I expect that host.accept binds value of the input and click of the button as a dynamic binding and just transfers the values of min and max; like, I have written:

<template>
    <input type="text" value.bind="value" min="3" max="20"  />
    <button click.delegate="onClick()">Search</button>
</template>

If I use host-transfer.bind for dynamics there is a possibility that the user of the component just does not bind any value for the property I assumed or designed as bindable, in some scenarios they may be used just like statics, what would happen then? Will host-transfer use it as static?

<search-bar value.bind="criteria" color.bind="maroon" click.delegate="searchGoods()"></search-bar>

Or

<search-bar value.bind="criteria" color="maroon" click.delegate="searchGoods()"></search-bar>

what should I write here for color attribute?

<template>
    <input type="text" host-transfer="min, max" host-transfer.bind="value" />
    <button host-transfer.bind="click">Search</button>
</template>

Any ideas?