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

> If the object has an event listener, we don't need async getters, as the value can be set as part of the listener.

Yeah, that's one way I was thinking about it - this would be the most simple / straightforward approach, as it would give JS a guarantee of *consistency* (everything in the same sync block is going to get the same values for a fetch's priority). It would, however, be sacrificing some degree of realtime *accuracy*.

The *other* way to do it would have it be like [`performance`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) and/or [MutationObserver](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver), where the value is *always* read *directly from the live state* (a la `performance.now()` or MutationObserver's `takeRecords()`), and when the change callback / event fires, it aggregates *all changes that happened between the last instance of the callback and now* (a la MutationObserver's `observe()`).

This is a bit of a complication to handle what essentially amounts to edge cases (and a queue-draining behavior like `takeRecords()` may not be desirable or necessary, versus a buffer / only-the-latest-state approach like how Performance does it), but it would be *robust*, and it would be *equally consistent*.


-- 
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-282021217