Once multiple events are configured, it is important that redundant events are not sent to the server. For instance, ICE-6584 was concerned with both "change" and "blur" events being sent to the server for the same user event. In the case that both are configured, it is likely sufficient to send only the "change" when it occurs, but send the "blur" when it occurs with no associated "change". Fortunately in this case the "change" is triggered prior to the "blur", so the "blur" could be discarded on the basis of a previous "change" being sent from the component.
More advanced cases will likely require the events to be buffered for a short time period to allow the event queue to be inspected and coalesced prior to sending. (The deterministic strategy above for "change" and "blur" would still be preferred, however, since it would not introduce any delays or the possibility for sending different events based on timing.)
Once multiple events are configured, it is important that redundant events are not sent to the server. For instance,
ICE-6584was concerned with both "change" and "blur" events being sent to the server for the same user event. In the case that both are configured, it is likely sufficient to send only the "change" when it occurs, but send the "blur" when it occurs with no associated "change". Fortunately in this case the "change" is triggered prior to the "blur", so the "blur" could be discarded on the basis of a previous "change" being sent from the component.More advanced cases will likely require the events to be buffered for a short time period to allow the event queue to be inspected and coalesced prior to sending. (The deterministic strategy above for "change" and "blur" would still be preferred, however, since it would not introduce any delays or the possibility for sending different events based on timing.)