aurelia vNext, bindable working unexpected

[vegarringdal]

@fkleuver

@bindable({ attribute: 'name' }) AttributeName = 'Im missing!!'

Looks like it adds just a new variable to class called "name"
Expected behavior is that it will use "AttributeName"

Sample:
https://stackblitz.com/edit/aurelia-vnext-bug001?file=helloWorld.ts

[fkleuver]

Nice find! this particular scenario was not unit tested yet, so that's about to change :)

[vegarringdal]

Great :-)

Here is a sample on binding being slow.
https://stackblitz.com/edit/aurelia-vnext-bug003?file=helloWorld.ts

You dont notice it on rendered, but when using 'bind someattribute.bind="somevar" the variables is not set when bind/bound and attached is called

[bigopon]

What the hydrate element instruction looks like:

{
  "res": "hello-world",
  "instructions": [
    {
      "value": "some-text",
      "dest": "name"
    }
  ]
}

dest should be AttributeName, instead of name. It's an issue with template compiler unable to understand aliasing.

[fkleuver]

Interesting. So this is not binding being "slow", but rather everything else being too fast :P
In vCurrent, we're using micro tasks at various places throughout the lifecycles. The reason why bindings are always done before attached is called is because attached is queued in a second-layer microtask after the microtask that the bindings run in.
In vNext, the TaskQueue is gone from the core and everything is completely synchronous except for updates to the DOM. You can overcome this by awaitng a promise of flushing the "new TaskQueue" which is changeSet.

What you found though is actually a bug that I need to fix, because binding updates certainly must propagate to downstream custom elements before attached is called.

I also noticed you seem a little thrown off by the lifecycle changes. Here is the HelloWorld custom element implement by hand: https://stackblitz.com/edit/aurelia-vnext-clarifications?file=helloWorld.ts
This is without the @customElement decorator, to show you how vNext roughly works under the hood. Keep in mind I'm skipping a few checks that vNext does because they're not relevant to the situation (such as shadow dom stuff)

@bigopon yeah this aliasing thing is a problem in resolveTarget, I got a fix ready soonish

[bigopon]

@fkleuver It could also be an issue with @bindable decorator not specifying the right attribute for template compiler to understand too. Could also be the combination of both. Glad you got a fix though

[vegarringdal]

@fkleuver

Interesting. So this is not binding being "slow", but rather everything else being too fast :P
In vCurrent, we're using micro tasks at various places throughout the lifecycles. The reason why bindings are always done before attached is called is because attached is queued in a second-layer microtask after the microtask that the bindings run in.
In vNext, the TaskQueue is gone from the core and everything is completely synchronous except for updates to the DOM. You can overcome this by awaitng a promise of flushing the "new TaskQueue" which is changeSet.

I still think all @bindables should be set before the bound/attached is called.
This feels a little weird to flush changes in the bound to get bound variables.
But maybe its just me. I understand flushing to update UI, but not internal variables. 🙈

---

I also noticed you seem a little thrown off by the lifecycle changes. Here is the HelloWorld custom element implement by hand: https://stackblitz.com/edit/aurelia-vnext-clarifications?file=helloWorld.ts
This is without the @CustomElement decorator, to show you how vNext roughly works under the hood. Keep in mind I'm skipping a few checks that vNext does because they're not relevant to the situation (such as shadow dom stuff)

Thanks for making this👍
Forked it so I dont loose it and can use it to learn more.

I did look at parts lifecycle after I got fusbox to use ts source by adding ts:main to package.json (used src folder... hoping it worked 😂, had issues with sourcemaps working correctly, but think that is issue or something I did wrong in my fusebox config )

I think there is a bug in the bound() callback, made own issue on it yesterday.
#100
Great if you can have a look at this and correct me if Im thinking wrong

[fkleuver]

I still think all @bindables should be set before the bound/attached is called.

Correct and this is how it works. As I clarified further on, there is currently a bug. The bug only applies to binding from one custom element to another. It queues the updates but it should only queue updates that end up at the DOM. this PR will fix that and you will not need to flush anything during bound.

I think there is a bug in the bound() callback, made own issue on it yesterday.

I'll reply in that issue

[vegarringdal]

OK, just had to make sure.
Closing this issue since being worked on 😄
Thanks again for taking the time to respond.