AnchorTo scrolls the page to an element by its id, with easing and a fixed offset from the top. The scroll itself comes from the @terrahq/anchor-to package: a trigger, a destination, an offset. The trigger can be a button, a link or a <select>; the package listens to click on the first two and to change on the select.

The framework part is in AnchorTo.js. A slider, an accordion or a pinned section between the trigger and the destination is lazy loaded, so when the user clicks, it may not exist yet and the destination is measured too high. Before creating the package instance, the class reads src/js/resources.js, takes every library registered with modifyHeight: true and fires eventSystem.loadEvent for each. Every handler answers its own <Name>:load event by building all of its instances at once, so by the time the scroll starts the page already has its final height.

// AnchorTo.js: before scrolling, load every library registered with modifyHeight: true
loadHeightModifyingLibraries() {
  const libraries = getModules();
  const heightModifyingLibraries = libraries.filter((lib) => lib.options?.modifyHeight);
  heightModifyingLibraries.map((lib) => {
    this.eventSystem.loadEvent({ library: lib.name, where: "AnchorTo" });
  });
}

The markup

A trigger with the js--anchor-to hook and an anchor-id attribute, which is the id of the destination. It is a plain attribute, not data-anchor-id. For a select, the hook is js--anchor-select and every option value is an id; no attribute needed.

<!-- The trigger: anchor-id is the id of the destination, no data- prefix -->
<button class="c--btn-a js--anchor-to" anchor-id="destination">Go there</button>

<!-- Or a select: every option value is the id of a destination -->
<select class="c--form-select-a__item js--anchor-select">
  <option value="destination">Destination</option>
</select>

<!-- The destination, anywhere below or above -->
<h2 id="destination">Destination</h2>

The handler

Two configs in Handler.js, one per hook. The button one resolves the destination from anchor-id once, when the instance is built; the select one leaves it out, since the package reads the id from the chosen option on every change. Both use an offset of 120px and never touch the URL:

this.config = ({element}) => {
    return {
        trigger: element,
        destination: document.getElementById(element.getAttribute('anchor-id')),
        offset: 120,
        url: "none",
        eventSystem: this.eventSystem,
    };
};

this.selectConfig = ({element}) => {
    return {
        trigger: element,
        offset: 120,
        url: "none",
        eventSystem: this.eventSystem,
    };
};

What the framework does for you

• Lazy loading. A trigger is only wired when it gets within 30px of the viewport (Boostify scroll). The package is imported once and cached by the Manager.
• Page transitions. Every instance is destroyed before swup replaces the content and rebuilt on the new page.
• Cross-handler events. AnchorTo fires loadEvent for every modifyHeight library: Collapsify, Slider, SliderKit, Lottie, ToggleGallery, PinnedScroll, StickyScroll. The chapter strip under the hero of every docs page is a list of these anchors.

The common case. The button carries anchor-id="destination" and the heading at the bottom of the live example has that id. Click it: the page eases down and stops 120px above the heading.

Between the two there is tall content on purpose: a slider and an accordion, both lazy loaded and both registered with modifyHeight: true. Without the load step they would still be empty boxes when the scroll starts and the heading would end up out of view. With it, AnchorTo builds them first and the destination is measured at its final place.

<button class="c--btn-a js--anchor-to" anchor-id="destination">Anchor button</button>

<!-- Tall content in between: a slider and an accordion, both registered with modifyHeight -->
<div class="c--slider-a js--slider">…</div>
<div class="c--accordion-a js--collapsify-accordion">…</div>

<h2 id="destination">Anchor To destination</h2>

Same package, other trigger. With a <select> the package listens to change instead of click and takes the destination from the value of the chosen option, so one select can point to as many sections as it has options. The config has no destination: there is nothing to resolve until the user picks one.

<div class="c--form-group-a">
  <label class="c--label-a" for="goto">Go To</label>
  <div class="c--form-select-a">
    <select id="goto" class="c--form-select-a__item js--anchor-select">
      <option value="a">a</option>
      <option value="destination">Destination</option>
      <option value="b">b</option>
    </select>
  </div>
</div>

this.selectConfig = ({element}) => {
    return {
        trigger: element,
        offset: 120,
        url: "none",
        eventSystem: this.eventSystem,
    };
};

HTML

Config (Handler.js, passed to the package)

eventSystem in the Handler.js configs is not a package option: AnchorTo.js keeps it to fire the load events and passes the rest on. To make a library take part in that step, register it in resources.js with options: { modifyHeight: true } and answer its <Name>:load event in its handler.