Add invokeApply option to $http

[offsky]

$timeout has the 'invokeApply' option that allows you to skip dirty checking. It would be very handy to have this option on $http as well.

Why: My application has a periodic $http request to look for updates on the server. 99% of the time there are no updates. It would be more efficient if angular could not run through the entire apply() loop in these cases, which can cause performance issues if the page has lots of bindings. I am getting around this right now by using jquery ajax and calling apply() myself, but I would prefer to use angular's $http.

[btford]

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!

[offsky]

I still think that adding an invokeApply option to $http would be valuable.

[cburgdorf]

Makes sense to me. $timeout and $http seem to be somewhat similar in that they both kick off an async operation. Since $timeout offers the possibility to not call $rootScope.$apply automatically it would make sense in terms of symmetry to have that option on $http as well.

[david-driscoll]

This should be a pretty low impact change, would it open for a pull request?

We could simply add a new option invokeApply that matches the naming of $timeout, and simply skips the $scope.$apply() call in the done() callback. This would also need to be added to $resource for the the action options object.

[uglow]

+1

[IgorMinar]

this is not so simple. http is fundamentally based on promises and angular's promises are made asynchronous via $digest queue, so making an $http call that doesn't cause $digest would require the http promise to use some other async queue mechanism (e.g. setTimeout, or something better).

I doubt that this will happen in 1.3 as it is a pretty big change.

[konsultaner]

+1

[booleanbetrayal]

+1 - would be a great feature to leverage in logging frameworks, etc

[Javarome]

+1
Other frameworks such as rxjs will trigger (or not) different async calls depending on success or error. Having an option to disabling auto-apply would help in implementing such callbacks consistently.

[gkalpak]

@caitp : Now that we have $$q wouldn't it be easier to add this feature ?

[caitp]

Sure

[okonovalenko]

+1 from me, I consider it a very useful feature. There are scenarios when you have many isolated business components/directives on the page that make many $http calls, some of those request promises get aggregated, developer needs to be in control of promise callbacks triggering $scope.$apply() and maybe do it only once at the very last promise resolution.

[strille]

+1 from me as well.

[philBrown]

I'm having some success by directly calling $httpBackend. At least it means you don't have to include another library like jQuery.

[Narretz]

See #12557

[dragosrususv]

This would be an awesome feature for large applications that use multiple pooling ajax calls. Big +1.

@IgorMinar : we may let the user debounce several ajax calls and have him manually trigger the $digest via $evalAsync/$timeout --- it's the whole point of avoiding the $apply no?

Can we get this merged soon?

[onemenny]

I agree, this is not just for polling, it's relevant for many http requests scenarios. There are already pull requests so what's keeping it outside of the master?

[ronnieoverby]

I need this, too....

[poshest]

+1

As a side question: @dragosrususv why should we avoid $apply? It seems circuitous to do a $evalAsync/$timeout when you can just do it directly.