@hostListener is well known within the community. Rather unknown are the problems this might have on runtime performance and general application architecture. In general, there are three main problems with using the
- Missing composability
- Performance issues
- Lacks configuration options
Before tackling those two problems more in detail, let's have a look at the example code used to demonstrate the problem.
To do so let's have a look at the following Stackblitz example, particularly the
Here we see an implemented drag'n'drop feature, using the
@hostListener decorator. In total, we registered 3 listeners.
mousedownevent, which we are using to set a property signalling that our drag'n'drop is about to start.
mousemoveevent, which calculates the position of the rectangle according to the mouse position.
- Finally, we are using the
mouseupevent to signal that our drag'n'drop has ended.
Do note that we used
document as eventTarget. We needed that to handle fast mouse movements which might be out of sync with the position of the rectangle. One will notice that when moving the mouse very fast, that one is out of the rectangle element, which would stop our drag'n'drop.
Let's have a more in-depth look at the problems listed above.
Taking a look into the code, we will notice that we set the property
true as soon as the
mousedown event happens. We use that property to perform an early return inside of the
mousemove event handler to stop this function from execution. This is the only way we can compose those two events, which is quite expensive because this
mousemove function is still executed with every mouse movement. In terms of composition, this drag'n'drop feature is fairly straight forward. There are several much more complex event composition scenarios, which become extremely difficult when using the
This problem is mostly the resolution of the missing composability. The problem here is that we register the 3 event listener, mentioned above, for every component instance, even though it's impossible to drag'n'drop multiple rectangles at the same time. Therefore what we should aim for is, that only the
mousedown event listener is registered for every component and just when this event happens we register the other events accordingly. Doing all this logic within the event listener function is a lot of work and also decently complex. Additionally, there is currently no way to disable a registers
@hostListener function. This is also the reason why the code example above constantly listens to mouse move events, even though they are not relevant if there isn't a rectangle selected before.
addEventListener provides an argument for configuration options (the description below is copied from the MDN web docs):
Booleanindicating that events of this type will be dispatched to the registered
listenerbefore being dispatched to any
EventTargetbeneath it in the DOM tree.
Booleanindicating that the
listenershould be invoked at most once after being added. If
listenerwould be automatically removed when invoked.
true, indicates that the function specified by
listenerwill never call
preventDefault(). If a passive listener does call preventDefault(), the user agent will do nothing other than generating a console warning.
One can clearly see that those configuration options are very powerful. For sure, one probably don't need to use them for every case. But especially for heavily event-oriented features this configuration options are key. If we take a look at the offical Angular documentation we will see, that we are not able to specify these configuration parameters, when using the
We have two different approaches to tackle the problems described above. Depending on your knowledge some of them are more or less complex. Let's have a look!
Theoretically one could register nested event listeners. Therefore we could use the
addEventListener function to register the event listeners.
Looking at the code example one will notice that this is fairly complex. Especially because we need to take care of registering and unregistering the nested event listeners. Even if all of the problems described above can be solved with this approach, In my personal opinion, I think that this is a very complex and hard to understand solution.
The second alternative approach would be using the RxJS
fromEvent operator. RxJS shines when it comes to composition of event-oriented code.
Having a look at this code, one will notice that just looking at the lines of code that this is the smallest approach. I have to admit that one needs to be familiar with RxJS to understand and write such code. It's not really intuitive, but therefore RxJS takes care of registering and unregistering the event listener for us. Additionally, we have many more opportunities regarding composability. That's one of the key benefits of using RxJS when dealing with event-oriented code.
If you want to understand the used operators you can have a look at the following blog posts:
@hostListener decorator is handy if we just want to listen to single events and don't rely on any kind of composition. Everything that involves a certain event composition should be implemented by using one of the other approaches listed above. In general,
@hostListener lacks features that are necessary when dealing with event composition. It completely misses cancellation options and any kind of composability. Those features are crucial when building heavily event-oriented features.
When you are used to RxJS you should probably use the
fromEvent operator to perform any kind of complex event handling. If RxJS is not your preferred technology, maybe using plain old
addEventListener might be a viable option for you.
This blog post aims to elaborate on different approaches to deal with event composition. It never intends to blame or hurt someone who was involved in the design or implementation of the
@hostListener feature. I personally appreciate any work that was put into that.