UpgradeAdapter sets incorrect keys in ng1 directive controller

[palmanis]

• I'm submitting a bug report

Current behavior
If ng1 directive controller has properties bound using bindToController and if the instance variable name is different from the attribute being read, then while using it through UpgradeAdapter, the controller gets all those properties with the attribute names and not the instance variable names.
for e.g.

controller: function () {
  this.first;
  this.second;
  this.third;
},
bindToController: {
  first: '<firstValue',
  second: '=?secondValue',
  third: '=?'
},
controllerAs: 'vm'

The when you use the directive upgraded from UpgradeAdapter, then upon inspecting the controller these show up as:

vm.firstValue
vm.?secondValue
vm.?

Expected/desired behavior
The values in controller should be populated in the variables first, second and third.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via
  Here's a plunkr to reproduce/see this issue.
  https://plnkr.co/edit/0FCNd7bQ9zM3jKTViD2t?p=preview
  If you notice i use the upgraded directive as:
  <ng1-directive [first]="'one'" [second]="'two'">
  And i have printed all the controller variables in the output and they end up as:
  First:
  Second:
  FirstValue: one
  Entire Controller: {"?secondValue":"two","firstValue":"one"}
• What is the motivation / use case for changing the behavior?
  Because of this bug, directives which have such bindings (which are genuinely required in some cases) do not work as expected. And frankly this is one of the numerous bugs we are coming across while using the UpgradeAdapter, using which is a pretty frustrating experience. It definitely does not work as it's expected to as per the guide.
• Please tell us about your environment:
• Angular version: 2.0.0-beta.17
• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

[wawyed]

Any updates on this issue? Seems quite important to being left for this long.

[gkalpak]

I am 92.456% sure that this has been fixed. @wawyed, are you still seeing this error with the latest version?

[gkalpak]

So, it hasn't been fixed for the "old" dynamic version, but it works correctly for upgrade/static 😞

[wawyed]

We are using dynamic upgrade adapter.

[wawyed]

So.. Is this going to get fixed? Do I need to raise a different issue?

[gkalpak]

Yes, it is going to get fixed (on 4.x at least), but I strongly recommend to start using upgrade/static as soon as possible 😃

[wawyed]

Why? Is the dynamic upgrade going to be removed?

[gkalpak]

@wawyed, I am not sure about that (nor is it for me to decide). The reason I recommend upgrade/static is that is supports AoT and has a better API imo.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}