The behavior introduced by 3a65822, which automatically unwraps promises returned by functions invoked by $parse, prevents any consumer of an expression from handling promise resolution on its own. More pertinent discussion of the problem exists here: #3503
Notably this breaks the typeahead directive in UI bootstrap, as per this issue: angular-ui/bootstrap#949
Here's a simple example of why this change is problematic.
http://plnkr.co/edit/ymxbpR?p=preview
The directive in that plunk executes a function on click (in the same way as ng-click) and expects a promise to be returned, which it will use to decorate the link with loading text.
Because $parse unwraps the promise, the directive has no chance to add its own handlers. If you switch the Angular version to 1.2.0rc1, it works as expected. I don't believe this is an uncommon use case, and certainly not one the framework should prevent from being possible. I hope this can be resolved by the next RC.
The behavior introduced by 3a65822, which automatically unwraps promises returned by functions invoked by
$parse, prevents any consumer of an expression from handling promise resolution on its own. More pertinent discussion of the problem exists here: #3503Notably this breaks the typeahead directive in UI bootstrap, as per this issue: angular-ui/bootstrap#949
Here's a simple example of why this change is problematic.
http://plnkr.co/edit/ymxbpR?p=preview
The directive in that plunk executes a function on click (in the same way as
ng-click) and expects a promise to be returned, which it will use to decorate the link with loading text.Because
$parseunwraps the promise, the directive has no chance to add its own handlers. If you switch the Angular version to 1.2.0rc1, it works as expected. I don't believe this is an uncommon use case, and certainly not one the framework should prevent from being possible. I hope this can be resolved by the next RC.