| 00:34 | <rbuckton> | I'm regularly disheartened that AbortController was standardized in WHATWG and not here. It's design privileges DOM APIs over user APIs in a way we very likely wouldn't have chosen, and now were essentially stuck with something that only gets us about 50% of what the language actually needed out of cancellation. |
| 00:45 | <ljharb> | yupppp. it's likely going to happen with observables too, and maybe with signals |
| 02:38 | <Richard Gibson> | 👋 looks like I'll be there |
| 02:38 | <littledan> | I don't see a particular chance of this happening with signals. I apologize that development has so far been in private; it's just been me and some framework people, trying to get something concrete and validated. All members of this group are happy to work with TC39. I expect to be able to share a draft by April at the latest (which is much later than I was expecting previously). |
| 02:40 | <littledan> | I think we can recover the situation with AbortController. It will be a lot of work, though... I think many people recognize that the current state is not perfect. It's just very hard to do basic things with the current API, e.g., correctly subscribe to an AbortSignal today in a way that doesn't leak memory in certain cases. |
| 02:41 | <littledan> | I've raised some concerns about observables on their issue tracker, and not yet seen a response from Google. I'm not sure how they're working towards conclusions on the many issues they have open. I don't understand what they plan to get out of an origin trial that they couldn't get with a polyfill (this isn't like new web platform capabilities--the polyfill will be complete). I worry that it will ship prematurely. |
| 03:33 | <Justin Ridgewell> |
There's a Signals proposal? |
| 03:35 | <littledan> |
|
| 06:06 | <Justin Ridgewell> | Reading the docs, it's building on Angular's signals impementation |