feat(template): auto infer binding expression when empty

[bigopon]

📖 Description

Our binding syntax comprises of 3 parts: target, command and expression as per the following formular:

target.command="expression"

Currently, when expression is absent, or empty, like the following examples:

<input value.bind="">
or
<input value.bind>

it's treated as an empty string, which means the template above works like this:

<input value.bind="``">

This is a missed-opportunity in v1, where we could have better dev experience, like suggested in #1259 . When the expression is either empty or absent, we can infer the expression based on the target. so for the above example, it should be understood as:

<input value.bind="value">

All binding commands that will share this behavior are:

• .bind
• .one-time
• .to-view
• .from-view
• .two-way
• .attr

This is technically a breaking change, but no-one would write anything meaningful with empty expression so the effect of this should be small, or none. Though it's still safer to have this done in beta so we don't cause unnecessary discomfort.

🎫 Issues

Close #1259

cc @fkleuver @Sayan751 @brandonseydel

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.54%. Comparing base (eaf2cd7) to head (98b3d43).
Report is 2 commits behind head on master.

❗ Current head 98b3d43 differs from pull request most recent head ebc8f0c. Consider uploading reports for the commit ebc8f0c to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1963      +/-   ##
==========================================
- Coverage   88.62%   88.54%   -0.08%     
==========================================
  Files         272      272              
  Lines       22823    22812      -11     
  Branches     5292     5281      -11     
==========================================
- Hits        20226    20200      -26     
- Misses       2597     2612      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ghiscoding]

@bigopon I'm trying to upgrade to Beta 17 and I'm getting a few errors as shown below in my Aurelia-Slickgrid demos, all of the code that fails have the @bindable decorator in this CI Failing Workflow in this PR

TS2488: Type 'Record<string, PartialBindableDefinition>' must have a 'Symbol.iterator' method that returns an iterator.

I don't exactly understand what I'm supposed to do in order to migrate? If I remove all the @bindable then it compiles without error but all my E2E tests then fail.

Here's code for 1 example that I have (code ref link)

export class Example21 {
  @bindable() selectedColumn!: Column;
  @bindable() selectedOperator!: string;
  @bindable() searchValue = '';

Do you have a clue what the errors are all about? Taking a look at the Bindable docs, it seems all the same.

[bigopon]

@ghiscoding this likely is a typing issur. Can you try bindable() as any to see if theres any runtime error?

[bigopon]

Nvm, sorry I forgot we rewrite decorator code with convention plugin. This likely is a types issues from rewritten code.

[bigopon]

@ghiscoding we have a test for this scenario too in our e2e, though a difference is in our setup we use transpileOnly here https://github.com/aurelia/aurelia/blob/master/packages/__e2e__/3-hmr-webpack/webpack.config.js#L36-L42
This is the reason why we didn't catch the issue. For now, you can apply the same change to temporarily work around it, will fix soon. Thanks!

@obedm503 you don't like this change?

[obedm503]

I don't like implicit behavior. An empty binding should result in an error. Even something.bind="" should be an error instead of an empty string.

[ghiscoding]

@ghiscoding we have a test for this scenario too in our e2e, though a difference is in our setup we use transpileOnly here https://github.com/aurelia/aurelia/blob/master/packages/__e2e__/3-hmr-webpack/webpack.config.js#L36-L42 This is the reason why we didn't catch the issue. For now, you can apply the same change to temporarily work around it, will fix soon. Thanks!

@obedm503 you don't like this change?

Thanks that worked, even if it wasn't an obvious fix. 👍🏻

[bigopon]

... implicit behavior. An empty binding should result in an error ...

I think when faced with an empty string, we have 2 choices: strict (throw) and helpful (infer).

We can choose to be strict, but I think being helpful would be nicer, especially if it's not obscure, which is the case for our change here. Whatever the expression is can be seen from the attribute, there's nothing hidden at all.

[ghiscoding]

We can choose to be strict, but I think being helpful would be nicer, especially if it's not obscure, which is the case for our change here

I agree which is why I wrote here because I wasn't sure what to do since the message was confusing