HTL client v3 API includes methods and properties organized into groups, and is publicly available on the HTL global instance, named htlbid by default. It is assumed in the examples of this page that the HTL global instance is named htlbid , but publishers may rename it as they wish.
These methods are always available:
newPage resets HTL to a state as if it is just loaded and initialized, e.g. htlbid.newPage() . Arguably, one of the consequences is that all existing slots are destroyed.on listens to an HTL event, e.g. htlbid.on('ad.init', (e) => console.log(e)) . Note that the event data is different from the data received by the event handler registered internally or in CustomJS via events object. The event data of on is part of the public APIs and exposes a limit set of data so that internal states are not messed up by the publisher. This is an advanced method that usually is not supposed to be used by the publishers.setUserData as per setUserData specification.These methods, mainly for managing HTL slots, are available when any API groups of divs , layout , and imperative are selected:
refresh refreshes all the HTL slots, e.g. htlbid.refresh() ;refreshSlot refreshes a single slot, e.g. htlbid.refreshSlot(slotOrDivId) ;getSlot returns the public interface of the specified slot, const slot = htlbid.getSlot(slotOrDivId) ;enableDebug is not supposed to be used by publishers in general.Static configurations for HTL client. as defined on HTL UI, are exposed on the global HTL instance. config is the entry object for the exposed configurations. Currently only Prebid.js configurations are available at config.prebid , e.g. const prebidGroups = htlbid.config.prebid.groups. We may add or change more in future.
This includes one method display , e.g. htlbid.display(). It searches DOM for eligible ad DIVs for HTL client to show ads. This also supports data attributes on the DIVs like data-unit for GAM, data-gpid for Prebid.js, data-eager for lazy loading, so on and so forth, when their respective modules are enabled. Note htlbid.display only searches DOM by one pass when it is called, and does not monitor changes in DOM afterwards, nor it does any more searches automatically.
htlbid.layout works the same way as htlbid.display, but monitors DOM and searches for ad DIVs over and over again automatically, e.g. htlbid.layout() . It also accepts argument false to stop monitoring DOM, e.g. htlbid.layout(false) . For being backward compatible with v2, any values other than false are deemed as starting monitoring DOM. Starting (or stopping) monitoring again when it has been started (or stopped) has no effect.