Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

Does the observing pattern being discussed here allow for the following use case?

Some applications that use service workers are online-first, but they might still want to handle flaky/poor internet connections using offline capabilities.

Currently, you can accomplish this using streams (like this: https://jakearchibald.com/2016/streams-ftw/). The idea is to call fetch, and once you get the response back start reading the response body. If you don't get enough of the data within a certain time period, you decide the internet connection isn't good enough and respond from cache instead or redirect to a url that serves a cached response.

It would be really nice if this spec accounted for this use case, as using streams feels too low-level and somewhat hacky.

The main requirements to make this possible are:
- having well-defined progress events that allow you to see what % of the data you've received (this seems to be proposed already in Jake's [comment](https://github.com/whatwg/fetch/issues/447#issuecomment-281731850)
- somewhat granular progress events and/or having the ability to specify how granular your progress events are. For example, if you get progress events every 5% of the way then you can detect a poor connection much faster/more accurately than if you only get progress events every 25% of the way.

-- 
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/447#issuecomment-287922120