Re: [ServiceWorker] Returning a FetchPromise from fetch() (#625)

This is just pulling the "cancellation" ability into the core `Promise`.  That's possible, but I don't think we want to go that way unless absolutely necessary.

@otakustay Reviewing your example from earlier, I see I missed a possibility.  Here's the example again:

```javascript
var p = waitForUserConfirm('press OK to continue').then(() => fetch(url));
```

You correctly pointed out that this'll cast the `FetchPromise` back into a normal `Promise`, which is unfortunate, and I thought that was a killer objection.  But it's not!  It's not the most ergonomic, but you can get around this by just converting the first `Promise` into a `FetchPromise` first:

```javascript
var p = FetchPromise.resolve(waitForUserConfirm('press OK to continue')).then(() => fetch(url));
```

This upgrades your original `Promise` into a `FetchPromise` with no-op cancellation behavior.  With this, the `.then()` properly assimilates the return value of `fetch()`, maintaining the `FetchPromise`-ness, so you can still cancel it.

So we can continue looking at type-based solutions rather than token-based ones, which makes me happy because they have much better ergonomics.

(The one problem, looking forward, is that they don't compose; you can't really make a promise that is both a `FetchPromise` and a `FooPromise`, for some interesting new value of `Foo`.  This seems identical to the problem of mixing monads; you just need to write the equivalent of a monad transformer to handle combining capabilities.)

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-76638427