Event Batching

HAPI Elements widgets use web components that inject iframes under the hood and rely on an event-driven architecture to communicate between the parent page and widget iframes. Every interaction -- from mounting a DOM element to applying a style change -- is transmitted as an event via postMessage.

Previously, each event was dispatched individually as a separate postMessage call. When many events were triggered in a short period (for example, during initial page load or when applying multiple UI customizations at once), this could lead to a high volume of cross-iframe messages and degrade runtime performance.

Events of the same type are now collected over a short window and dispatched together in a single batched message, reducing the number of cross-iframe postMessage calls and improving overall responsiveness.

The following events are batched:

• Element mounted and element unmounted events, triggered when DOM elements mount or unmount inside widget iframes
• Iframe unloaded events, triggered when a widget iframe is removed from the page
• DOM events such as scroll, triggered when a listened DOM event fires inside a widget iframe
• hideElement and showElement
• hideElements and showElements
• setStyle and setStyles
• setStyleAttribute and setStyleAttributes
• setAttribute and setAttributes
• addClass, removeClass, addClasses, and removeClasses
• addStyleSheet and removeStyleSheet
• appendChildToSlot and removeChildFromSlot
• scrollTo and getScrollPosition
• Icon change events

The plural UI Submodule functions (hideElements, showElements, addClasses, removeClasses, setAttributes, setStyles, setStyleAttributes) additionally collect matching operations over a short debounce window before dispatching, providing an extra layer of batching on top of the event-level batching.

This optimization is transparent to integrators -- the JavaScript API behaves the same way as before. No changes are needed in existing integrations.