2025-05-07 [18:27:59.0904] 👋 Hey team! I'd like to introduce myself and andrew-cnv . We're working for Canva, a web based online design platform. We're currently looking to improve our telemetry in the product and have come across Async Context. We were wondering if we could attend the next meeting and get a lay of the land. The future topic on usable polyfills to test with is especially interesting. We were also wondering what are the blockers for this proposal reaching stage 2.7. [18:28:57.0937] Hi! The main blocker for stage 2.7 is figuring out exactly how the context should propagate across the many web APIs, especially events [18:30:30.0634] currently Mozilla is blocking the proposal because they think the complexity in implementation (if every single event that is caused asynchronously by some web API needs to have the context propagated) would not be worth the use cases [18:31:32.0108] * currently Mozilla is blocking the proposal because they think the complexity in implementation (if every single event that is caused asynchronously by some web API needs to have the context propagated) would not be worth it considering the use cases [18:34:01.0374] Does Mozilla have recommendations or a path forward? Is there any way we can help? [18:34:26.0874] * Does Mozilla have recommendations or a path forward? Is there any way we can help? (Also thanks for the background!) [18:35:14.0309] it'd be really helpful to know if the current web integration works for you, and in particular whether you need it to work for some specific async events [18:35:17.0636] https://github.com/tc39/proposal-async-context/blob/master/WEB-INTEGRATION.md [18:56:20.0673] Regarding the current web integration, I think the one that jumps out at me is ResizeObserver. From what I read, it sounds like the callbacks themselves will be run under the empty context. This presents a problem as we're looking to figure out how much rendering work is the result of certain actions in the UI. These actions may be resizing some parent container, and have that change propagated down to child elements. I note that you mention certain observations may expose the causal snapshot related to that particular observation. The specific callout was PerformanceEntry, but I was wondering if ResizeObserverEntry is in that bucket? [18:58:11.0359] it wasn't so far [18:59:19.0046] I don't know how easy that would be to implement, I'll look into it [19:00:38.0047] (That same problem applies to IntersectionObserver as well) [19:00:48.0577] in any case, exposing the causal snapshot in specific kinds of observers is something that can be added later without risking web compat concerns, which isn't the case for extending propagation of almost everything else in the proposal [19:02:14.0285] For more context: We've been experimenting with using Zone.js to do this context propagation. We're not happy with the limitations that are imposed by using Zone.js and was looking to see how far away Async Context would realistically be. [03:10:47.0782] A few months back, I built a lightweight polyfill. https://github.com/iliasbhal/simple-async-context It’s fully tested and I’ve used it in several projects (nothing quite at Canva scale 😄 ). Feel free to try it out—I’d appreciate any feedback, especially if you hit edge cases or have a unique use cases. 2025-05-08 [19:05:40.0737] Hey Andreu Botella I've had a deeper read of the WEB-INTEGRATIONS document and especially at the Events section. I'm interested in the difference between the "Browser-originated dispatches" and "Asynchronous dispatches" and specifically what is meant by 'where the event originates from JS calling into some web API'. What constitutes a JS call into a web API here? Is it only explicit function calls, as given in the XHR examples? Or would it include events fired implicitly by the rendering of components. The example I have in my mind is the following: We have a component that renders something, and that component has an animation defined in css. Work is done after the transition is completed, via 'transitionend' event. That can obviously happen from a number of different paths. Would the context that scheduled the work be considered 'some web API'? 2025-05-13 [00:33:26.0259] Huh, good question. So you're thinking of, e.g. changing some class from JS, which triggers the animation? Tracking that would not be easy