Binding DOM events using observables

[wesleycho]

I'm submitting a ... (check one with "x")

[ ] bug report
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
With the DOM renderer, one binds events just like one does when using the raw DOM api (i.e. addEventListener).

Expected/desired behavior
Being able to interface with an observable for binding DOM events.

What is the expected behavior?
Being able to interface with an observable for binding DOM events and still retain the benefits of server-side/mobile platform rendering with support for progressive web apps.

What is the motivation / use case for changing the behavior?
Currently there is no exposure to being able to manipulate an observable, which prevents easier implementations of certain behavior, such as throttling a scroll event (say for a scrollspy), or dragging & dropping components. It would also be more in line with rxjs paradigms & its integration within Angular.

Ideally, one should be able to do

this.domRenderer.createListener(this.elementRef.nativeElement, eventName)
  .throttle(50)
  .subscribe(...);

[fknop]

Check this operator: https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/fromevent.md

[wesleycho]

I'm familiar with it - however, the point of it needing to be in the renderer is because of server-side rendering.

[nadavsinai]

I have thought about this issue too, I made a little helper directive
for that cause , as @fknop said it's easy to use .fromEvent, but since we don't want to access the dom directly the right way would be to use (for example with click event)

 let teardown:Function, listen = (handler:Function)=> {
        teardown = this.renderer.listen(this.$element.nativeElement, 'click', handler)
      };
      this.clicks$ = Observable.fromEventPattern(listen, ()=>teardown());
    });

this is exactly what i'm doing for now, but framework support would be much prefered.
It would be awesome if we can use the template to get DOM event observables, just as easily as we can get eventHandlers.
I was thinking of of $ at the end of the event name which will make the compiler create an observable rather than register for the event handler directly.

<button (click$)='myClickObs'> </button>

Obviously the programmatic access @wesleycho asked for would also be beneficial.

[robwormald]

see #4062, it would cover this functionality and is planned

[wesleycho]

I actually was proposing an imperative feature for this - given that it is possible to bind events imperatively, this would allow a matching API for doing so with observables.

For example, consider a Bootstrap scroll spy - one would want a throttled event listener. My preference would be to only have one event listener, but perhaps making use of a more declarative API like suggested could work too (although I'm guessing there are some negative ramifications perf-wise due to multiple observables being created for each element being spied on - it may be acceptable though).

If a single event listener is used, then this event listener sits on a top level component, or is added by a service. The API doesn't seem to integrate well with accessing DOM outside of a directive, so that would mean that it would probably have to be handled by a service.

In order to accomplish the throttling, instead of being able to make use of observables, one would have to move the throttle implementation inside the event listener.

I would be happy with whatever solution is adopted & approach blessed.

[DzmitryShylovich]

I think one can be closed in favor of #13248

[DzmitryShylovich]

@pkozlowski-opensource ☝️

[pkozlowski-opensource]

Yep, let's move it over to #13248