Improving ergonomics of events with Observable

Observable has been at stage 1 in the TC-39 for over a year now. Under the circumstances we are considering standardizing Observable in the WHATWG. We believe that standardizing Observable in the WHATWG may have the following advantages: * Get Observable to web developers more quickly. * Allow for a more full-featured proposal that will address more developer pain points. * Address concerns raised in the TC-39 that there has not been sufficient consultation with implementers. The goal of this thread is to gauge implementer interest in Observable. Observable can offer the following benefits to web developers: 1. First-class objects representing composable repeated events, similar to how promises represent one-time events 2. Ergonomic unsubscription that plays well with AbortSignal/AbortController 3. Good integration with promises and async/await ### Integrating Observable into the DOM We propose that the "on" method on EventTarget should return an Observable. ```cs partial interface EventTarget { Observable on(DOMString type, optional AddEventListenerOptions options); }; [Constructor(/* details elided */)] interface Observable { AbortController subscribe(Function next, optional Function complete, optional Function error); AbortController subscribe(Observer observer); // TODO this overload is not quite valid Promise<void> forEach(Function callback, optional AbortSignal signal); Observable takeUntil(Observable stopNotifier); Promise<any> f

Posted by benlesh on Dec 13, 2017, 5:58 AM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0