hmm, i'm not a TS user. 🤷‍♂️

Testing it now...

(another thing that's nice is responses can be returned using either

return

or

yield

, so you can use existing callbacks as-is, just add an asterisk!)

huh that is interesting. I guess it means we'd have to check whether the handler returns a promise vs. an iterator and handle differently?

yeah, would definitely need some more logic on your end, probably looking for

Symbol.asyncIterator

on the returned value.

it's very pleasingly elegant. Though in practice I frequently see cases where

waitUntil()

is being called by some deeply-nested function, requiring passing the

event

object down to it... I guess refactoring that sort of code to use this instead would be weird.

but maybe we could support both

we're diverging from the service worker spec now so we can do what we like... 🙂

exactly. i think that API served you very well when workers was basically a proxy.

but clearly it's getting a bit limiting.

Not immediately. Might need a bit of wangling. Seemingly despite what it says in the docs (https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-6.html), TS isn't immediately inferring the two types separately. It thinks that

value

could be either a Response or void.

i also think async iterators could help usability on other parts of the platform, like KV/DO list operations, etc.

yeah the thing that really bothered me about Service Workers was the non-composability. You can't take two service workers and just "link" them together into one, unless they carefully handle disjoint URL patterns.

i mean, classic DOM API story, really.

heh

taken further, deno for example uses top-level async iterators.

(i'm not saying this makes sense for cloudflare workers, but definitely makes it easier to not have to define bespoke APIs)

that might be getting a little bit to cute for me. 🙂

it makes more sense when you own the logic for starting the server.

i agree it's not good for your workers.

but how do you refactor it to handle multiple kinds of requests?

multiple async iterators, one per type i guess?

I guess you just have an async function for each request type, and then call them all...

Used them quite a lot for listing all the keys in KV: https://github.com/cloudflare/workers-types/issues/32#issuecomment-633119231

but then your API would be ugly, because you'd have to wrap each in an IIFE to prevent blocking, i guess.

yeah

one thing that's kinda weird about the CF module implementation is that you use both default and named exports.

ie,

export {MyDurableObject}

but also

export default {fetch}

.

kinda makes the actual output API harder to grok, since i'm not sure too many folks actually know the difference.