Restrict behavior of custom attribute single value binding and primary bindable

[ekzobrain]

Restrict behavior of custom attribute single value binding and primary bindable

[bigopon]

Thanks for the issue @ekzobrain , just to clarify: the current behavior is if theres no bindable defined, then we target the value property on the custom attribute instances. Otherwise the primary bindable will be targeted in the single binding mode.
A bindable is considered primary if its one of the following:

• the only bindable, or
• the bindable with primary: true in is config, or
• the first bindable when there is no primary defined

I think your case should work by default, or maybe can you provide a repro so its clearer whats missing?

[ekzobrain]

My major case is when I have a single bindable and don't want it to be assigned with attribute value (I don't want any bindable to be considered primary). But I have no way to do this now. And the overall approach seems too complicated and inconvinient. There are too many if/else in this logic :)
I suggest a simpler approach:
define primaryProperty on customAttribute definition, not on bindable. Then, by default, it would be value, but may be changed to any other property name, or disabled completely with null value (see my last two examples).

[ekzobrain]

This repro highlights my issue: https://stackblitz.com/edit/au2-conventions-u5ygqi?file=src%2Fsome-attribute.ts,src%2Fmy-app.ts,src%2Fmy-app.html
But it's just one of many similar cases, when bindable has data type other than string, or some default value.

[bigopon]

@ekzobrain I think the idea of moving primary to the custom attribute definition sounds good, it's been quite an annoyance since primary is on @bindable but only custom attribute cares about it. We can make it backward compatible by checking whether primaryProperty is defined or not.

If it's not defined (backward compat), then it'll automatically pick the one with the rules mentioned:

the only bindable, or
the bindable with primary: true in is config, or
the first bindable when there is no primary defined

If it's defined then it'll take over the process of defining primary bindable.

Thoughts @fkleuver @Sayan751 @jwx @brandonseydel @Vheissu ?

---

Though I think this is also related to a more general issue: what to do when the initial binding value is undefined from the parent.

[Sayan751]

I also like the idea of moving the primary bindable information to the custom attribute. That might take some burden off the bindable definition.

Though I think this is also related to a more general issue: what to do when the initial binding value is undefined from the parent.

I think if a value is bound (identifiable from the compiled instructions, I guess), then that value will be assigned, even if it is undefined. One can always employ setters in @bindable, if that does not suffice.

[bigopon]

After some moment of aha, I think we can at least partially address this issue by making empty binding as no binding. For custom attributes, empty binding mean an empty string as expression, for example:

<div my-attribute>

I don't think anyone would want to say: create a custom attribute my-attribute, and let it have an empty string as value.
With this change, the default value should be able to be retained when there's no actual binding.

For when there's actual binding, but empty values (undefined/null/""/actual value), it's the actual value so I think we can leave it alone, like in these example:

<div my-attribute="val">
<div my-attribute.bind="`...`">
<div my-attribute="${...}">

[bigopon]

I created a PR here #1930
It should address the issue with the cases you mentioned @ekzobrain
For the template

<div my-attr="val">

I think the intention is too clear that the attribute wants to bind to the primary bindable with a value val literal string, we probably shouldn't change that.

[ekzobrain]

I agree with this partial solution. At least it solves the main issue when attribute is used without any intentional value