| 15:29 | <littledan> | Awesome! Let's get this on a WHATNOT agenda soon. |
| 22:00 | <Steve Hicks> | I got some feedback from Peter Burns (of Web Components and Lit): https://docs.google.com/document/d/1nAgNZni5F2zU6ET88suvtwSu15y5sEFMngF75tkc8Hk/edit |
| 22:02 | <Steve Hicks> | tl;dr is that the current proposal isn't particularly helpful in his estimation - partly due to the always-registration-time semantics, and partly due to a mismatch where the DOM tree and the execution tree aren't necessarily aligned 1:1, and they tend to favor the former over the latter. |
| 22:04 | <Steve Hicks> | what he'd like to see is a bifurcation of functions where some (e.g. schedulers) would use registration contexts and others would just "do nothing" - i.e. just use whatever synchronous context was already there, don't do any restoration. |
| 22:04 | <Steve Hicks> | And the web component lifecycle callbacks would want to be the latter |
| 22:06 | <Steve Hicks> | My take on all this is that we may still have some iterating to do on the dom integration... :-/ |
| 22:07 | <littledan> | "do nothing" isn't always so easy to define because it may come after some async step--there isn't always JS on the stack immediately before |
| 22:08 | <littledan> | for web component lifecycle, sometimes there is and sometimes there isn't JS on the stack, right? |
| 22:09 | <littledan> | like for parser-constructed DOM |
| 22:09 | <littledan> | anyway if we can define these cases, I think it'd be fine to add that to the spec. It'd be some kind of WebIDL extended attribute. |
| 22:13 | <littledan> | anyway this seems to be swinging back in a direction which I proposed previously: that we apply the snapshot with the "most information", that is, to "do nothing" when it can possibly make sense. The downsides to this were (1) complexity of getting this all figured out on the first go (2) "Zalgo"/it's complicated for people to mentally model what's going on |
| 22:27 | <Steve Hicks> | The zalgo situation is the most concerning part. I'd be more comfortable if it's statically determined per API. So something like - lifecycle callbacks are always unwrapped, events are always wrapped. Unwrapped callbacks have an opt-out by manually wrapping them. Wrapped callbacks _may_ have an opt-out via a snapshot property. I'm still not convinced that it's a problem to sometimes run a callback in the top-level/initial snapshot (e.g. if it's dispatched from the parser). |
| 22:34 | <Stephen Belanger> | The safest escape from Zalgo is generally just not create it in the first place, so I feel like if we consistently “do nothing” it might be okay. Some Web APIs are just detached from any reasonable context flow and so would probably be fair to propagate nothing unless a manual wrap is made. 🤷 |
| 22:37 | <Stephen Belanger> | From a technical purity perspective I’d like to think of that as a root/unit context which all else descends from, but thinking of it in that way doesn’t necessarily require making any specific action to describe it that way programmatically. Rather, it requires explicitly not doing something as Dan says where we may reach a point where a thing could trigger synchronously and so we may want to specify those APIs to explicitly bail out from the current context. |
| 23:19 | <Steve Hicks> | Maybe the most constructive thing to do would be to comment on #100? |
| 23:45 | <Justin Ridgewell> | I don’t think AC is really useful for Lit’s design, because everything is easily accessible from the Element (this) instance |
| 23:46 | <Justin Ridgewell> | React’s functional components + hooks are the best example of need, because the API doesn’t use a context object to place values on, it has to be ambient. |