Ability to monitor request progress

[alh84001]

It would be useful to be able to have access to (XHR) client progress, ideally through the promise returned. If that is not feasible at least the ability to mixin progress listener would be nice. Currently XHR client is created, then it is opened, and then the properties are mixed in. For download progress it would be sufficient to do the mixing ('onprogress' property) before opening the connection, but this won't work for upload progress.

(edit: I see now that this is somewhat related to issue #79 as well)

[mosch]

👍 would love to have this feature.
@alh84001 we can open a PR if we have a good implementation. In what way would you add the upload progress to the promise? Upload progress is not supported by all clients, so i think this must be an optional feature.
The XMLHttpRequest fires the "onprogress" event.
I think a good way would be to have a interceptor with a config value "progressCallback" that get's called if the client has such events.
@scothis i can't find a way to get access to the client in the interceptor. can you help with this?

[scothis]

@alh84001 The general issue is that promises don't handle progress events reliably. So much so, that when.js is planning to drop support for progress. The trick is figuring out the best way to pass the progress events, allowing interceptors to work with them.

I did a PoC with streams a while back, the code is still available. I didn't cary it forward because it introduced a good bit of overhead, and most interceptors still required buffering the response. Someday, browsers will support proper streams

@mosch To your specific question, it's intentionally difficult to get access to the underlaying request mechanism inside an interceptor. The interceptor should not know (or care) about the underlying transport. The best hack would be to fork rest/client/xhr, adding a callback for readyStateChange 3 events.

Sorry I don't have a good answer at the moment. The streams work is the most promising though.

[briancavalier]

Any thoughts on possibly using a most.js stream for progress? For example, a stream of the response chunks. It may not be the right fit, since this is really more like I/O than FRP, but I figured I would put it out there for discussion.

[scothis]

Closing in favor of #101