Automatic unwrapping of promises by $parse severely limits its usefulness

[wilsonjackson]

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.

[IgorMinar]

would it be sufficient if $parse took an optional argument that would tell it to not unwrap promises?

[IgorMinar]

@jankuca your PR #3681 could handle this in an easier way than the current closure based code. could you take a look at this and create a commit on top of that PR that would implement the promise unwrapping flag?

[jankuca]

Sure, I'm going to look into it.

[wilsonjackson]

Sure, an optional argument would solve the problem, though to me opting in to promise unwrapping would make more sense than opting out.

[IgorMinar]

@wilsonjackson fair enough. we'll consider it

[jussik]

I mentioned this in my PR that this issue stemmed from, but please make sure that functions returning promises are processed the same way by $parse as promise objects in scope. I don't mind unwrapping being opt-in, but keep in mind that promise objects have been unwrapped automatically for a long time now.

[pkozlowski-opensource]

@IgorMinar an optional opt-in argument would be a perfect solution. We really need it badly for the angular-ui/bootstrap. @jankuca if I help anyhow I could give you a hand with this issue, I'm really keen on doing anything that would speed up this issue resolution.

[wilsonjackson]

I agree that promise objects should be unwrapped (or not) according to the same rules whether they result from a function call or not.

I'd argue that promise unwrapping is an "extra" feature that is not intrinsically related to parsing, so it would make the most sense for it not to happen by default. Also, the time to introduce breaking changes is now. I think this is the perfect time to correct this slight overreach in $parse's implementation.

[jankuca]

I did some work regarding this issue: jankuca/angular.js@dddc774...promise_unwrapping

But we need to get #3681 first.

[georgiosd]

I'll second that this is a pretty big breaking change and it doesn't allow for knowing when the promise is resolved for actions.

And now I'm between a rock and a hard place, as RC1 has broken ngIncludes and RC2 has this broken :S

Does anyone know what direction you'll take after all so I can at least work around only one of the issues?