You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it is possible to have one declaratively defined debounce setting for @DomEvent, there is no easy way of making a component API that allows users to customize the debounce settings for individual listeners.
One challenge with implementing something like this is that the current implementation only adds one listener to the Element even if multiple component-level listeners are registered. A single element listener only supports having one debounce setting. Even if multiple settings would be possible, there would also be a challenge with routing each element event to the correct component listeners.
Another challenge lies in the way the same addListener method is also used for listeners that aren't annotated with @DomEvent, for which debounce settings wouldn't make any sense.
It should also be considered how to make it clear that the debounce settings are only effective for events originated from the client, but not in cases where the same event can also be fired from the server (e.g. value change events triggered through server-side setValue methods).
The text was updated successfully, but these errors were encountered:
While it is possible to have one declaratively defined debounce setting for
@DomEvent
, there is no easy way of making a component API that allows users to customize the debounce settings for individual listeners.One challenge with implementing something like this is that the current implementation only adds one listener to the
Element
even if multiple component-level listeners are registered. A single element listener only supports having one debounce setting. Even if multiple settings would be possible, there would also be a challenge with routing each element event to the correct component listeners.Another challenge lies in the way the same
addListener
method is also used for listeners that aren't annotated with@DomEvent
, for which debounce settings wouldn't make any sense.It should also be considered how to make it clear that the debounce settings are only effective for events originated from the client, but not in cases where the same event can also be fired from the server (e.g. value change events triggered through server-side
setValue
methods).The text was updated successfully, but these errors were encountered: