Re: [whatwg/dom] Allow postMessage-ing AbortSignal (#948)

> That seems reasonable to me and is compatible with what we are planning to do for Fetch (see [whatwg/fetch#1343](https://github.com/whatwg/fetch/pull/1343)). (The current plan there is to serialize/deserialize abort reason and recreate the `AbortSignal` as we already have a channel with the service worker, but it's not distinguishable from the above I think.)

I'm happy to make a PR if you want.

> There is a challenge here since given that the structured clone algorithm doesn't handle custom Error objects well without losing data. Some platforms that might not be able to handle DOMException as a host object, for instance, might not be able to deserialize it as a DOMException on the receiving end.

This is part of the wider issue of not having any userland way of having custom structured serialized things. How do existing structured clonables/transferables like `MessagePort` work in Node?

Nowadays it might be more viable to have userland structured cloning by just pointing to an ES module for deserialization. With [module blocks](https://github.com/tc39/proposal-js-module-blocks) the ergonomics of it could even be rather nice as you could just return a module block from some hypothetical serialize method. This is just an idea on my part and is well beyond the scope of this issue though.

-- 
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/dom/issues/948#issuecomment-983284554