Provide method to get EventType of listener

[haenni]

Describe your motivation

Currently, it is not easily possible to get the number of registered listeners for a certain, exact eventType.
Method com.vaadin.flow.component.ComponentEventBus#getListeners does also include subTypes of the given eventType, which is not always wanted.

For example the call eventBus.getListeners(ItemClickEvent.class) returns a collection that also contains listeners for ItemDoubleClickEvent, since it is a subType of ItemClickEvent. Distinguishing the eventTypes in the returned collection is cumbersome.

Describe the solution you'd like

It would be helpful if there was a method that given a listener, returns its exact eventType. The method signature would be something like public Class<? extends ComponentEvent> getListenerEventType(Object listener). This would allow to iterate over the collection returned by com.vaadin.flow.component.ComponentEventBus#getListeners and check the eventType for every listener.

Describe alternatives you've considered

Using reflection.

[Legioth]

It might be useful to have an understanding of what you're really trying to achieve, i.e. why you care about the number of listeners of an exact type?

[haenni]

@Legioth
Sure, I will try to explain:
We have an internal testing tool, that allows an app tester to record and replay custom test scenarios (for more details on this see vaadin/flow-components#2261 (comment)). There are situations, where we do not want to record an event.

Lets say the app has a view with a Button on a VerticalLayout. If the tester clicks the button, both the button and the layout will get a clickEvent due to event propagation. But the tester clicked only once, so we should record only one click into the test script.
So we count the registered listeners to check if the app under test also registers its own listener besides the one from the testing framework. Only then will we record the event into the script.

Another example is a grid in SingleSelection mode. The testing framework registers a listener for itemClickEvent, itemDoubleClickEvent and SingleSelectionEvent. The app only registers a SingleSelectionEvent.

Currently, both itemClickEvent and itemDoubleClickEvent are considererd itemClickEvents, which causes the itemClick event and the selection event to be recorded. But the user performed only one action. So we should record the select event only. Even worse in this case: The select event comes before the click event, so if both are recorded the trailing click actually causes the item to be deselected again during replay.

[Legioth]

Maybe you would need a way of looking for listeners for a given DOM event type (e.g. item-double-click) regardless of the Java event type?

I guess you could filter out those by using GenericTypeReflector to inspect the actual event type for each listener and then checking the value of the @DomEvent annotation (if present). But maybe that's the cumbersome solution that you're referring to?

[mshabarov]

Would it be enough for your cases to have a similar method to eventBus.getListeners(ItemClickEvent.class) , but that has a contract to return only listeners that correspond to exact given event type? To not do the extra work by requesting all listeners and filtering them.

[haenni]

@Legioth Thanks for your input but I would rather not want to work with the DOM-Event Types, since we primarily work with the Java event types. Right now we use reflection to access the field componentEventData of class ComponentEventBus. This works but we would like to get rid of reflection.

@mshabarov
Yes, that would be sufficient for our use cases.
I just thought that having a method that returns the exact eventType of a given listener might be more flexible and could in the future also be of value for other users / use cases.

[Legioth]

Semantically speaking, what you want is probably to find all listeners that would be invoked for a given user action.

The challenge here is that there are two fundamentally different ways through which user actions can lead to firing an event:

• fireEvent(ComponentEvent) is used for events triggered through server-side code, e.g. button.click(). Listeners to invoke are looked up directly based on event.getClass() without even considering sub classes.
• handleDomEvent(Class<T>, DomEvent, ListenerWrapper<T>) is used for events triggered directly from the browser through Element::addEventListener. Listeners to invoke are (indirectly) based on @DomEvent annotations on the event class. In a hypothetical scenario with multiple unrelated event classes that have a similar @DomEvent annotation, then listeners of both event types will be invoked. @DomEvent is @Inhertied which means that an event subclass without its own @DomEvent annotation will also be considered.

And the really confusing part is that neither of the two ways are directly compatible with the way getListeners(Class<? extends ComponentEvent>) looks up listeners based on Class::isAssignableFrom.

[haenni]

@Legioth Not exactly. What we generally do is generating code that imitates a given user action ("record" the user action). When the generated code runs ("replay" the user action), the user action should be imitated as closely as possible, meaning the same events in the same order should be fired as when the action was recorded. Or in other words, the replay of a user action should produce the same chain of events as if the user action was performed by a real user. This can sometimes be tricky and involves some logic to ignore "unwanted" events during recording. See examples above. One part of that logic is to count event listeners of an exact specific type.

So we would like a solution as proposed in the OP or the one suggested by @mshabarov above.

[Legioth]

How does that work with a hypothetical web component integration where some user interaction fires a DOM event named e.g. my-event? My understanding is that you would then want to record that my-event was fired? The tricky thing there is that this would trigger listeners for both @DomEvent("my-event") public class Event1 { ... } and @DomEvent("my-event") public class Event2 { ... } even though there's no inheritance relationship between Event1 and Event2. There's no such case among the standard components included in Vaadin but you might hypothetically have something like that with add-ons or custom components in the application.

[haenni]

Unfortunately, things are not always that straight-forward and it is usually hard to tell what to do given a hypothetical situation. There are different approaches to work around recording too many events. It very much depends on the use case at hand. Counting the listeners is one such approach.

Another example is the way to make sure no server-originated event gets recorded (since of course these are no user interactions): For the most part we can rely on the isFromClient property of an event. But there are exceptions, for example in the case of com.vaadin.flow.component.grid.Grid#select(T). The implementation of this select method executes JS on the client, so property isFromClient of the corresponding SelectionEvent is true. Our workaround in this case is to query the stack on the server and ignore the event in case the call was made programatically.

As for the hypothetical situation above: A possible solution could perhaps be to only consider the first event per round-trip on the component or something like that. But I am just guessing here. If and when confronted with such a scenario, we would need to examine exactly what is happening and then come up with a solution if it does not work out of the box. These solutions are not always very nice and like in the case of this ticket sometimes require reflection. So an API extension on the part of Vaadin would be appreciated.