Way for single event subscription? #65

saschanaz · 2023-09-15T08:44:22Z

I think this proposal is mostly for repeated events, but is there corresponding way of once: true in addEventListener?

Something like:

await element.on("click").takeImmediately()

The text was updated successfully, but these errors were encountered:

domfarolino · 2023-09-15T10:06:49Z

Oh, I filed #66 and wrote #67 (which removes once: true from the event listener options that we use) before seeing this by the way. We could keep once in the event listener options, although it seems like your desire is not to use that directly, but instead introduce an operator that more-or-less gives you a Promise for a single Observable event, right? We've discussed adding .toPromise() recently (in contrast with toArray()), which I think offers some pretty explicit language, but also we have .first() currently commented-out in our WebIDL sketch, which I think satisfies this but with less explicit language. How do any of those sound?

My thought is that the .on() method would always create an Observable (over the "add event listener" internals) whose teardown is to remove the event listener. Something like toPromise() or first() would subscribe to the observable, and unsubscribe after the first event (thus removing the event listener like once: true would). Maybe we could just uncomment first() or rename it to toPromise() or takeImmediately()? I might prefer toPromise() to be extra explicit about the scheduling impact.

benlesh · 2023-09-21T20:28:56Z

One problem with a promise returning API is that you'll have an event in a different async context, where e.preventDefault() is too late.

This can be done like so:

await element.on('click').take(1).forEach(e => {
  // Do what you need do with the even in here.
  // Since this is synchronously dispatched, things like
  // e.preventDefault() can still be used.
});

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 supported 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. [email protected] Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47

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 supported 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

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

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}

…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N 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} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455

…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N 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: benbenlesh.com R=masonfchromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Dominic Farolino <domchromium.org> Cr-Commit-Position: refs/heads/main{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455 UltraBlame original commit: 152cc51982905b4522338a38f9542e691a6a93e3

…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N 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} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455

domfarolino · 2024-04-03T15:17:12Z

At this point we've decided to add the first() Promise-returning operator (see #131 and #126) which I think satisfies this request, and @benlesh has kindly provided a nice example to keep synchronous scheduling when needing synchronously react to the "first" event (in order to preventDefault() or something like that).

I'll set up #131 to close this issue once merged.

chromium-wpt-export-bot mentioned this issue Nov 30, 2023

DOM: Observable EventTarget integration 1/N web-platform-tests/wpt#43455

Merged

domfarolino mentioned this issue Apr 3, 2024

Spec the first() operator #131

Merged

domfarolino closed this as completed in #131 May 5, 2024

domfarolino mentioned this issue Jun 11, 2024

EventTarget, Observer, and toArray, last, etc #149

Closed

domfarolino mentioned this issue Jul 10, 2024

Observable API w3ctag/design-reviews#902

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Way for single event subscription? #65

Way for single event subscription? #65

saschanaz commented Sep 15, 2023 •

edited

Loading

domfarolino commented Sep 15, 2023

benlesh commented Sep 21, 2023 •

edited

Loading

domfarolino commented Apr 3, 2024

Way for single event subscription? #65

Way for single event subscription? #65

Comments

saschanaz commented Sep 15, 2023 • edited Loading

domfarolino commented Sep 15, 2023

benlesh commented Sep 21, 2023 • edited Loading

domfarolino commented Apr 3, 2024

saschanaz commented Sep 15, 2023 •

edited

Loading

benlesh commented Sep 21, 2023 •

edited

Loading