- 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