Request/Upload progress handling via @angular/http

[akomm]

[x] feature request

Current behavior
When I want to attach to XMLHttpRequest.prototype.upload events using Http I need to put my hands on the default backend/connection provided and override the provider for Http injecting my modified backend/connection.

Expected/desired behavior
When I invoke .{get,post,put,...} on Http I want to be able to optional listen to upload progress of the underlying connection. I want to do so the least intrusive way. After a glance at source I see a possibility to implement an optional property on RequestOptions and/or Request object. It could be of type Subject. The abstract Connection could have an additional optional property progress of the same time.

• A Connection-Implementation, which supports progress could .next to the Subject, passing specified RequestProgressEvent interface, when the given option is not undefined.
• A Connection-Implementation which does not support it could either ignore it and not emit any events, or mock the state by just sending start and end events - not sure yet which way would be the best.

The RequestProgressEvent could abstract from concrete events used for example in XHR to a common interface, so that any Connection which supports it could adapt its internal impl. to this interface.

The usage could look like that:

let progress$ = new Subject<RequestProgressEvent>();
progress$.subscribe(event => {
    switch (event.type) {
        // do something ... different types, like timeout, progress, etc.
    }
});
// http: Http
// given the Connection used supports progress, ii would also .next upload events to progress$
http.get(url, {progress: progress$}).subscribe(/* ... */);

Sure the instantiation of Subject can be omitted by passing a shorthand next/error/complete to progress-option.

Something I'v overlooked that makes this not a good approach?

updated: Escaped less-than/greater-than characters for generic type, so they are now visible.

[tsvetomir]

That would be a welcome addition.

I don't see the point for a type field in the RequestProgressEvent interface. Fault conditions can be reported through error notifications.

[akomm]

@tsvetomir the type field was not meant to cover all event types of XMLHttpRequest.prototype.upload. Only those related to progress.

[goodmind]

any updates on this?

[atulatri]

+1

[pablomagro]

+1

[rafmagns-skepa-dreag]

+1

[DzmitryShylovich]

@rafmagns-skepa-dreag please use reactions instead if +1

there're no plans to add support for upload hangling because fetch has no support for progress and we don't want to tie http API to XHR long-term

[akomm]

You don't have to tie the http API to XHR. What is the point of switchable backends?
The upload/download progress can be abstracted from a specific JS API, so only a specific backend that touches a specific JS API (XHR/fetch) has to decide how and whether to provide the progress info.

A progress item next'ed could be as simple as { progress: float /* 0-1 */, determined: bool }
Fetch backend could just give 0 and 1 when finished plus determined: false, XHR could send percentages 0 to 1 and determined: true

Public http API would have no knowledge of XHR. Give backend an internal api that either accepts an subject to next progress or one that provides an observable for the http to subscribe to.

http does not care how backend get the data.
users of http don't care about how http gets the data.
XHR becomes deprecated, XHR using backend becomes deprecated, everything remains clean.

[alxhub]

I'm hoping to have progress implemented in the new HTTP APIs!