Ability to react to progress events of $http XHR

[ryankshaw]

I would like to be able to bind to the progress event of the xhr upload.

for example (in plain javascript):

var xhr = new XMLHttpRequest();
xhr.upload.addEventListener("progress", uploadProgress, false)

(so I can show a progress meter for uploaded files)

I want to be able to do the same thing by doing $http.post...

for this and any other case edge case where you need to interact with the raw XHR object itself it might be nice to provide something that lets you just get at the original xhr object.

[michaeltaranto]

+100! Really need to be able to access the internal xhr object of $http service.

[bjconlan]

Providing an 'xhr' config option (which I assume would be callback that gets the xhr instance passed in) is probably the simplest option to implement (and also means that we don't need to update angular every xhr spec change), but I think the correct way to do this is to extend the $q object to support a progress handler callback as per http://wiki.commonjs.org/wiki/Promises/A. This keeps with the nice abstraction angular provides to the $http object and since it is already based upon $q promises it could then provide something akin to what you are attempting to do (bind to the progress events)

Perhaps #2223 can help with this.

[aminariana]

+10

My issue is that I'd like to cancel the request if it wasn't completed upon new request.

I'm issuing many search queries async (depending on the user behavior) and there's severe race condition. The work-around I see right now is to fall back on jQuery.ajax method, simply because that's the only thing I'm familiar with that provides an XHR that I can cancel upon new request.

[trea]

+1 I'd also like to see something implemented for this purpose.

Thanks!

[magro]

+1

[miki725]

+1

[gustavohenke]

+1

[danialfarid]

+1

[anormal81]

+1

[lu4]

+1

[cgwyllie]

+1

[lovenigma]

+1

[bhalperin28]

+1

[Guuz]

👍 I was surprised when I noticed this is not possible in AngularJS...

[miki725]

Any plans to solve this. Maybe in 1.3?

[IlanFrumer]

+1

[miki725]

+1

P.S.: I already +oned however posting again since not sure if my initial "+1" will count towards the 1.3 feature poll.

[magro]

+1

[Guuz]

+1

[marcalj]

+1

[thvd]

+1

[michalkvasnicak]

+1

[gustavohenke]

@miki725 seems like it's planned for the 1.3 milestone :)

[standuprey]

+1

[atticoos]

It would be nice if we could just use the promise's progress callback

From kriskowal/q docs

promise.then(onFulfilled, onRejected, onProgress)

The then method from the Promises/A+ specification with an additional progress handler.

I see no reason why we can't use .then here and expect onProgress to be reported to

$http({
  method: 'POST',
  data: jsonData
}).then(function () {
  // on succes
}, function () {
  // on error
}, function () {
  // on progress
});

Or, if the .success and .error are preferred

$http.post(url, data).success(function () {
  // on success
}).error(function () {
  // on error
}).then(null, null, function () {
  // on progress
});

[benjamingr]

@ajwhite I humbly disagree, it would be horrible to use the progress event, not only is it being removed from Kris Kowal's Q (check the v2 branch) and the Q authors are themselves against it - it will not be included in native promises (ever) and is a generally poor idea.

Please refer to the above discussion starting here:

#1934 (comment)

[atticoos]

@benjamine please refresh, I noticed the depreciation notice in the docs & redacted

[atticoos]

@benjamine also caught up on your conversation. With the points being made towards the deprecation of all progress events, even in .then(null, null, progress), it makes less sense to build support for it this way. With Bluebird & Q moving away from that support, a configuration property seems to make a bit more sense, and leave promises to their responsibility

[benjamingr]

Glad we agree promise progress events are not the way forward :)

[caitp]

the progress api from promises is certainly not the way to do this (we've known this for some time, for instance, it would kind of suck to have to always register a progress listener for XHR, and we'd still not know whether we're talking about XHRUpload or just XHR, it doesn't map well to this api at all!)

Sooooo, basically, we need some other way to do this that plays nice with the current promise-y way of doing things, and don't really have that yet. :(

[benjamingr]

@caitp what's wrong with allowing optional callbacks to the options object of the $http call?

[arcanis]

About this :

should progress notification handlers automatically trigger $digest cycle (if they don't than the whole feature is a bit useless and if they do we need to be careful about not causing perf problems - maybe we should debounce those events and call handlers + $digest only every x ms?)

I think the debounce is a good solution. We don't need them to be called often, we just need them to be called enough to give some kind of feedback to the user. Even something like once per second would be enough, by adding some css transitions here and there.

[chrisirhc]

Since there are a number of progress events that can fire loadstart, progress, load, timeout, abort, error, … How about allowing the user to specify an object to attach the events (eventName: eventListener)?
For example the object could look like the following:

var eventCallbacks = {
  loadstart: function onLoadStart() {},
  progress: function onDownloadProgress() {},
  upload: {
    progress: function onUploadProgress() {}
  }
};

Then the $httpBackend, would call xhr.addEventListener(<eventName>, <function>); to attach the event listeners. Callbacks defined under the upload attribute would be bound to the xhr.upload.

This also allows for users to bind to readystatechange if they need to react to readyState == 3 loading events.

By stating that these are raw event listeners, you can also get around needing to invoke a digest as the user is expected to do so. It also gets around Angular needing to polyfill different browser's behavior.

I'll be happy to get a PR going.

[chrisirhc]

Added a PR #11547 to illustrate what I meant above.

[benatkin]

Here's a directive that has a clever but terrible hack to get around it.

How it works: it replaces window.XMLHttpRequest.prototype.setRequestHeader with a function that calls the original, except when it finds __setXHR_ with a callback function, in which case it calls it.

[nikkwong]

Is there any consensus on how best to achieve this for the time being?

[ryanki1]

This topic is already 2 years old - have we already made a start on implementing it?

[y-x-c]

+1

[nastakhov]

+1

[nicolas-alie]

+1

[weisk]

+1

[petebacondarwin]

Moved this to 1.5 - let's discuss the implementation at #11547