| 09:41 | <Daniel Mil, van> | Hello, I don't know if the question belongs here, but I was currently involved in a design question like https://discourse.wicg.io/t/waituntil-on-dom-events/2056 and was curious for the possible answer (see http://discourse.wicg.io/t/waituntil-on-dom-events/2056/3). Anyone? |
| 10:38 | <Domenic> | I think the comment right after the one you linked is the answer. |
| 12:34 | <Daniel Mil, van> | I think the comment right after the one you linked is the answer. |
| 12:34 | <Domenic> | It doesn't support async dispatching. It supports giving a promise to the browser which tells it not to shut down the service worker until the promise is done. |
| 12:34 | <Domenic> | That promise doesn't extent event dispatch in any way |
| 12:34 | <Domenic> | (E.g. you cannot cancel the event asynchronously) |
| 12:35 | <Daniel Mil, van> | ah ok |
| 12:35 | <Daniel Mil, van> | interesting |
| 12:36 | <Daniel Mil, van> | I had to review some code and a colleage implemented something like: https://github.com/rektide/async-event-target |
| 12:37 | <Daniel Mil, van> | For some reason this doesn't seem right and I was wondering why this would be the case, but although it "feels" wrong I can't seem to find the good arguments not to do so |
| 12:40 | <Daniel Mil, van> | the comment here http://discourse.wicg.io/t/waituntil-on-dom-events/2056/3 also says: "That requires way too much changes", not that's it's not possible or not a valid use case? |
| 12:40 | <Daniel Mil, van> | we could also chat in private is this is not the place to discuss this here |
| 12:41 | <Domenic> | It seems fine to create your own thing if you have no other way of solving the problem. The platform doesn't provide it, and we definitely can't change every EventTarget on the platform to provide it. |
| 12:42 | <Domenic> | Heading to bed now myself, but others might have thoughts :) |
| 12:42 | <Daniel Mil, van> | thanks! |
| 13:02 | <annevk> | mek: https://github.com/whatwg/fs/pull/78 |