fix(ngMock#$controller): properly assign bindings to all types of controllers (e.g. class-based) #14439
Conversation
gkalpak
force-pushed
the
fix-componentController-assign-bindings-on-Class
branch
from
719e95e
to
eb55a07
Compare
|
Safari 9 doesn't like this: |
|
We can test on 9.1 though, maybe it was fixed by this version( I doubt it) |
|
Yeah, I saw it failed. I pushed a potential fix, but it failed again and I'm not sure why (I can't test locally on Windows). I'll try to track this down via SauceLabs' manual testing later (or tomorrow). |
|
Isn't that the same problem with have in compile with Safari? |
|
No idea :) |
|
I was thinking about this: #13785 |
|
@Narretz, it seems like it. So, does it mean that |
…trollers (e.g. class-based) The decorated version of `$controller` is able to assign bindings to a controller instance prior to instantiation, emulating the behavior of `$compile` with directive controllers. There are cases, that the actual controller instance is different than the pre-populated one (e.g. when the controller constructor function returns a value or when the controller is an ES2015 Class). While `$compile` accounts for such situation, by re-asigning the bindings after the controller has been instantiated, `ngMock`'s `$controller` didn't. This commit fixes it, by re-applying the bindings if the actual controller instance is different than the original one (similar to how `$compile` would do it). Fixes angular#14437
gkalpak
force-pushed
the
fix-componentController-assign-bindings-on-Class
branch
from
eb55a07
to
974cad9
Compare
|
That is indeed the case. I changed the class-based test to only run on Chrome (we are doing the same in the |
|
I'm thinking that may be it is also related to: #14206 |
|
LGTM |
…trollers (e.g. class-based) The decorated version of `$controller` is able to assign bindings to a controller instance prior to instantiation, emulating the behavior of `$compile` with directive controllers. There are cases, that the actual controller instance is different than the pre-populated one (e.g. when the controller constructor function returns a value or when the controller is an ES2015 Class). While `$compile` accounts for such situation, by re-asigning the bindings after the controller has been instantiated, `ngMock`'s `$controller` didn't. This commit fixes it, by re-applying the bindings if the actual controller instance is different than the original one (similar to how `$compile` would do it). Fixes #14437 Closes #14439
|
I still seem to have this issue with $componentController and angular 1.5.8 and ES6 classes, neither locals or bindings are being set on the controller instance. |
|
@tuhoojabotti It works fine for me, I have multiple tests that rely on that. If something's broken for you, please open a new issue. |
|
@mgol I just realized it's because of my test setup. I do not use ngMock because I can't get past calling flush on every http request, so I have my own mock module that exposes some ngMock providers, but I forgot to add the $controllerDecorator, that's why the bindings aren't being set. |
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix (I think).
What is the current behavior? (You can also link to an open issue here)
The bindings are not assigned to the final instances of controllers specified as Classes or returning a value from their constructor.
See #14437.
What is the new behavior (if this is a feature change)?
The bindings are assigned to any type of controller, similar to how
$compilewould do it.Does this PR introduce a breaking change?
Not really.
Please check if the PR fulfills these requirements
Other information:
The decorated version of
$controlleris able to assign bindings to a controller instance prior toinstantiation, emulating the behavior of
$compilewith directive controllers.There are cases, that the actual controller instance is different than the pre-populated one (e.g.
when the controller constructor function returns a value or when the controller is an ES2015 Class).
While
$compileaccounts for such situation, by re-asigning the bindings after the controller hasbeen instantiated,
ngMock's$controllerdidn't.This commit fixes it, by re-applying the bindings if the actual controller instance is different
than the original one (similar to how
$compilewould do it).Fixes #14437