Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOM: Observable EventTarget integration 1/N #43455

Merged
merged 1 commit into from
Dec 14, 2023

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Nov 30, 2023

This CL implements "limited" and "leaky" EventTarget integration with
the Observable API. See below for what "limited" and "leaky" mean.
Concretely, this involves introducing the on() method to the
EventTarget interface, so that all EventTargets can return Observables
that listen for events. This is the part that really makes Observables a
"better addEventListener()".

This is the first instance of a natively-constructed Observable, as
opposed to a JS-constructed Observable. This means the subscription
callback passed to the Observable constructor is not just a JS callback
function with user-defined code, but instead is a C++ delegate class,
called SubscribeDelegate which has its first concrete implementation
provided by EventTarget (in event_target.cc). The concrete
implementation of this interface that this CL introduces, adds an event
listener to the given EventTarget, upon subscription. The events are
forwarded to the Subscriber's next() method. This is what unlocks
more ergonomic event handling with the composable Observable primitive
and all of its (coming) operators.

  1. The EventTarget integration is considered "limited" because we do not
    support any of the AddEventListenerOptions yet, as of this CL. A
    subsequent CL will add support for a more restricted version of the
    AddEventListenerOptions, called ObservableEventListenerOptions,
    which does not include a once option, or an AbortSignal, since
    Observable operators and subscription is responsible for managing those
    aspects. Concretely, an ObservableEventListenerOptions will
    resolve to an AddEventListenerOptionsResolved accordingly. See:
  1. The EventTarget integration is considered "leaky" as of this CL,
    because there is currently no way to remove an event listener added by
    an EventTarget-vended Observable. This will come in a subsequent CL,
    which will pass the test that is currently failing in this CL. See
    How to removeEventListener? WICG/observable#75 for discussion about
    tying the subscription termination to removing an event listener.
    From a technical perspective, this is pretty easy — it involves adding
    an abort algorithm to Subscriber#signal (which has already been wired
    up properly by now!) that removes the given per-Subscription
    ObservableEventListener NativeEventListener from the associated
    EventTarget. That implementation has already been sketched out in
    https://crrev.com/c/4262153 and the design doc. It will included in a
    follow-up CL, to reduce the complexity of this one.

For WPTs:
Co-authored-by: [email protected]

R=[email protected]

Bug: 1485981
Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1237501}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

This CL implements "limited" and "leaky" EventTarget integration with
the Observable API. See below for what "limited" and "leaky" mean.
Concretely, this involves introducing the `on()` method to the
EventTarget interface, so that all EventTargets can return Observables
that listen for events. This is the part that really makes Observables a
"better addEventListener()".

This is the first instance of a natively-constructed Observable, as
opposed to a JS-constructed Observable. This means the subscription
callback passed to the Observable constructor is not just a JS callback
function with user-defined code, but instead is a C++ delegate class,
called `SubscribeDelegate` which has its first concrete implementation
provided by EventTarget (in event_target.cc). The concrete
implementation of this interface that this CL introduces, adds an event
listener to the given EventTarget, upon subscription. The events are
forwarded to the Subscriber's `next()` method. This is what unlocks
more ergonomic event handling with the composable Observable primitive
and all of its (coming) operators.

1. The EventTarget integration is considered "limited" because we do not
support any of the `AddEventListenerOptions` yet, as of this CL. A
subsequent CL will add support for a more restricted version of the
`AddEventListenerOptions`, called `ObservableEventListenerOptions`,
which does not include a `once` option, or an `AbortSignal`, since
Observable operators and subscription is responsible for managing those
aspects. Concretely, an `ObservableEventListenerOptions` will
resolve to an `AddEventListenerOptionsResolved` accordingly. See:
 - WICG/observable#66
 - WICG/observable#67
 - WICG/observable#65

2. The EventTarget integration is considered "leaky" as of this CL,
because there is currently no way to remove an event listener added by
an EventTarget-vended Observable. This will come in a subsequent CL,
which will pass the test that is currently failing in this CL. See
WICG/observable#75 for discussion about
tying the subscription termination to removing an event listener.
From a technical perspective, this is pretty easy — it involves adding
an abort algorithm to `Subscriber#signal` (which has already been wired
up properly by now!) that removes the given per-Subscription
`ObservableEventListener` NativeEventListener from the associated
EventTarget. That implementation has already been sketched out in
https://crrev.com/c/4262153 and the design doc. It will included in a
follow-up CL, to reduce the complexity of this one.

For WPTs:
Co-authored-by: [email protected]

[email protected]

Bug: 1485981
Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1237501}
@chromium-wpt-export-bot chromium-wpt-export-bot merged commit aeeea42 into master Dec 14, 2023
21 checks passed
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-5073394 branch December 14, 2023 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants