- From: Conrad Irwin <notifications@github.com>
- Date: Mon, 14 Aug 2017 20:12:59 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/577/322296331@github.com>
It depends how much buffering I guess. It looks like the XHR equivalent is pretty low fidelity (and if it's just bytes written, not bytes acked, also subject to queueing and over-promising).
For what it's worth, we have an internal fetch() wrapper that takes an `onProgress` callback, and falls back to XHR if it's specified. It seemed nicer than trying to figure out an evented way of doing it given that `fetch()` doesn't have an instance that you can attach events to.
```
fetch(url, {
body: blob,
method: 'PUT',
onProgress: ({status, loaded, total}) => {
// status is one of "loading" (before the returned promise resolves or rejects), "success" (after the returned promise resolves), "error" (after the returned promise rejects)
// loaded is the bytes transferred as reported by XmlHttpRequest's ProgressEvent
// total is the total bytes as reported by XmlHttpRequest.
}
})
```
I also considered having `fetch()` return a thenable event emitter instead of a promise; but because we're using a mix of promise libraries already, that seemed like a recipe for confusion.
Would love to see an official solution to this problem, either by specifying how much buffering is allowed in the ReadableStream case, or just adding a callback.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/577#issuecomment-322296331
Received on Monday, 14 August 2017 20:13:56 UTC