Re: [whatwg/dom] Proposal: asynchronous event listeners (Issue #1308)

Here is one short list of use cases for what "async events" might mean to folks, each with potentially different feature requests:

- "lazy loading controllers"
  - You don't have the code to attach to addEventListener loaded yet, but the UI is already presented and the user could already interact.
  - You want to delay any events from _starting to dispatch_, perhaps until some fetch / script finishes loading, or alternatively you just want a better mechanism to capture and replay the event later.
  - Note: once the event listener is loaded, it becomes a normal synchronous event listener.
  - Note: the declarative UI might have a declarative fallback (e.g. link click or form submit) but the imperative event might be "better" if allowed to load.  Perhaps a timeout decides when to dispatch the default action?

- "passive event dispatch"
  - This event listener needs to observe the event, but doesn't actually implement the core functionality of the event and doesn't need to be scheduled immediately and before next paint.
  - Already supported for various scroll events, and for specific features like Intersection Observer and some animation lifetime events, etc.
  - Easy to polyfill or workaround, as an opt-in, but might leave scheduling/performance opportunities on the table.
  - As a native feature, might be applied as a policy / intervention.  For example, constraining a third party script to only be allowed to register passive listeners.
  - Note: `{priority}` seems to me to imply "passive" yet gives even more control.

- "async effects which follow the sync event"
  - The use case @WebReflection lists.
  - Might still want to be able to `preventDefault` etc from the async., e.g. form validation which needs a network hop first.
  - Might want other web platform features, like performance event timing, to measure all the way to the end of async effects.
  - (Potentially?) has some overlap with AsyncContext / Task Attribution

- "document unload" use cases
  - Today you can easily block the _start_ of a navigation that would unload a document, but, once a document starts unloading there is a limited amount of time for script.
  - As a result, many scripts hook onto events and delay the default action (such as a link navigaton or form submit) from even starting, for fear of not having a change to observe the event at all when that event triggers document unload.
  - Perhaps we need a contract: This event listener is only passively attached to this event... but it should be "flushed" before unload.  (Reminder: these scripts are already blocking unload start, anyway)

- "document loading" use cases
  - Related to lazy-loading controllers but less fine grained.  We have `blocking=render` for first paint but we don't have a way to block all events on resources like script.
  - Very early interactions are racy, and the priority of event dispatch is unpredictably prioritized over async/defer scripts.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1308#issuecomment-2312993127
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1308/2312993127@github.com>