/**
 * Source of the generated `utils/pagination-scroll.js`.
 *
 * ## The problem
 *
 * A paginated array mapper renders its rows and, below them, a pagination block
 * whose previous/next buttons only move a piece of React state
 * (`ds_<n>_state.page`). Nothing navigates, so the browser has no reason to
 * move the viewport: the visitor scrolls to the bottom of page 1, clicks
 * "Next", and lands on the BOTTOM of page 2 — looking at the last rows of a
 * list they have not seen the start of.
 *
 * ## Why a delegated runtime rather than per-button code
 *
 * The pagination block is emitted from one UIDL element type
 * (`cms-pagination-node`), on pages and on components, once per paginated
 * mapper — thirteen of them in a default e-commerce project alone. A single
 * capture-phase listener on `document`, keyed off the marker the project plugin
 * stamps on that element, covers every one of them (including blocks mounted
 * later by a client-side route change or a conditional branch) without touching
 * the generated `onClick`s, and gives the behaviour one place to live.
 *
 * ## Which element it scrolls to
 *
 * The mapper renders its rows INLINE — there is no wrapper element around them,
 * because one would become a stray grid/flex item in the list's own layout. So
 * the rows are plain siblings of the pagination block, and the first row is the
 * first sibling that is not chrome. Two element types are chrome and are marked
 * as such by the project plugin: the pagination block itself and the mapper's
 * search/sort/filter block (`data-source-search-node`), which the generator
 * emits ABOVE the rows.
 *
 * On a listing page that lands exactly on the first product card. On an admin
 * table — toolbar, table, pagination — it lands on the toolbar, which sits
 * directly above the table header, so the first row is on screen either way.
 *
 * ## Why it corrects after the first scroll
 *
 * Between the click and the new rows arriving, the mapper paints its loading
 * state, which is usually shorter than a full page of rows. A list near the
 * bottom of a short document therefore has a start the browser CANNOT reach at
 * that moment and clamps the scroll to the document end. The correction loop
 * re-issues the scroll once the document is tall enough again, and hands
 * control straight back the moment the visitor scrolls for themselves.
 */
export declare const PAGINATION_SCROLL_RUNTIME_JS: string;
//# sourceMappingURL=pagination-scroll-runtime.d.ts.map