Angular CDK имеет широкие возможности для скроллинга плоского списка. Если размер каждого элемента одинаков, то можно воспользоваться FixedSizeVirtualScrollStrategy: всего лишь нужно прокинуть размер элемента в пикселях, проитерироваться по данным и виртуальный скроллинг готов. Но что делать, если размер элементов разный? Данную проблему можно решить кастомной стратегией виртуального скроллинга. Для моей задачи требовалось реализовать просмотрщик pdf-документа. Решение pdf.js не подходило, потому что этот инструмент не справлялся с рендерингом некоторых страниц в документе и обязательно требовал наличие самого файла на клиентской части. Этого мы не могли себе позволить, ибо имели действительно большие документы и не хотелось ждать, пока они скачаются. Поэтому было необходимо грузить документ частично. Но как тогда реализовать скроллинг? Наивно предполагать, что документ состоит только из страниц А4. В нашем случае, файл мог содержать все форматы страниц от А0 до А5. Это свойственно документам эксплуатации строительства, где содержатся много чертежей и пояснительных схем. Раз страницы разной размерности, то стандартная стратегия виртуального скроллинга для фиксированного размера элемента не подходит. Если посмотреть, как устроен формат pdf, то можно выяснить, что документ состоит из изображений и метаинформации. В метаинформацию входит: Текстовый слой. Разметка слов или фраз покоординатно относительно изображения. А также шрифты, ссылки, содержание и другое. Размеры каждой страницы. Раз размеры страниц известны заранее, то естественно пришла в голову идея писать кастомную стратегию виртуального скролинга. Спасибо за вдохновение этой статье. План был такой: Первым запросом получить необходимую метаинформацию для построения стратегии Каждый отрендеренный элемент будет дополнительным запросом грузить в себя изображение страницы. Метаинформацию для текстового слоя можно было бы грузить следом: дополнительным запросом. Я не буду детально рассматривать реализацию текстового слоя, потому что это бы нас увело от основой повествовательной нити. Этот слой можно отрисовывать поверх изображения с прозрачным цветом согласно полученным координатам. Тогда на документе работали бы все выделения, копирования и клики. Если посмотреть, как реализованы все популярные веб-просмотрщики (dropbox, google drive, acrobat cloud), то вы обнаружите именно такую реализацию. Итак, нам с сервера пришла необходимая метаинформация с размерами страниц. Пришло время построить стратегию виртуального скроллинга. С помощью токена VIRTUAL_SCROLL_STRATEGY (и всей красоты Dependency Injection) мы можем предоставить свой класс стратегии виртуального скролинга PdfVirtualScrollStrategy: В данном случае класс стратегии я предоставляю через фабрику, которая берет инстанс из текущего компонента. Для создания стратегии в классе необходимо реализовать интерфейс VirtualScrollStrategy: Здесь функции attach, detach отвечают за привязку и, соотвественно, отвязку стратегии к вьюпорту. Метод onContentScrolled вызывается на каждое изменение скролла. За изменением текущего индекса списка можно следить через scrolledIndexChange, а просколлить к нужному индексу можно через методscrollToIndex. В нашем случае, методы onDataLenghtChanged, onContentRendered, onRenderedOffsetChanged использоваться не будут, так как у нас не будет меняться длина списка, да мы и не будем обращаться к отступам списка через компонент CdkVirtualScrollViewport в обход стратегии. Так как метаинформация с размерами приходит с сервера, то мы имеем следующий поток pagesData$: Observable<PdfPageMetadataModel.View[]>. Чтобы предоставить эти данные в стратегию необходимо воспользоваться заранее подготовленным методом setData: Так как документ живет на протяжении работы пользователя, то размеры страниц могут меняться. Например, он может работать с масштабом или поворотом страниц, поэтому при каждом изменении мы будем изменять входные данные размеров и заново передавать в стратегию для перерасчетов. Настало время показать сам класс стратегии виртуального скроллинга. Здесь будут показаны самые простые методы, а сложные мы рассмотрим отдельно. В методе setData мы устанавливаем начальные значения данных размеров страниц, где через rangeStartIndex можно установить, с какой страницы необходимо показывать документ. Для моей задачи требовалось уметь из скроллинга переключиться в постраничный слайдер и обратно. Поэтому хотелось отрисовывать страницы сразу с предустановленной, что не вызывало бы дополнительных запросов. Если не передавать это значение или задать undefined, то по умолчанию начальной страницей будет первая. Далее в методе setTotalHeight мы считаем общую высоту всех страниц totalHeight. Аналогично находим и устанавливаем самую большую страницу по высоте в методе setMaxPageHeight. Это значение нам понадобится для вычисления буффера. Далее в методе setPagesDataOffsets вычисляем отступ каждой страницы от самого начала документа в двух значениях: стартовом и конечном. Например, для первой страницы начальный отступ от верха равен нулю, а конечный равен высоте страницы. Для последующих страниц аналогично: начальный отступ равен конечному отступу предыдущей страницы, а конечный — сумме конечного отступа предыдущей страницы с высотой текущей страницы. Для расчетов нам понадобится уметь вычислять индекс страницы по оффсету getIndexForOffset, а также оффсет по индексу страницы getOffsetForIndex. Однако так как мы заранее посчитали начальный и конечный отступы для каждой страницы, то необходимые выкладки становятся достаточно естественными: В методе getIndexForOffset условием possibleIndex < 0 && this.totalHeight <= offset * 2 мы гарантируем, что индекс последней страницы установится, если мы проскроллили больше половины списка. Теперь остается рассмотреть самый главный метод в классе виртуальной стратегии, отвечающий за отрисовку конкретного слайса списка. Рассмотрим все по порядку. Если индекс начальной страницы не установлен, то забираем значения scrollOffset и currentRange из вьюпорта. Однако, если установлен, то выставляем эти значения сами. Аналогично для дальнейших расчетов нам еще понадобится размер вьюпорта viewportSize и общая длина данных dataLength. Для скроллинга мы хотим грузить видимый слайс с некоторым запасом для более мягкой работы. Для меня это значение изначально было равно двум размерам видимой области. Однако, если есть потребность управлять масштабом страниц, то значение буффера должно быть коррелировано с высотой максимальной страницы в документе. Поэтому буффер у меня вычисляется как максимум двух этих значений: Первый видимый индекс страницы firstVisibleIndex высчитывается по scrollOffset: this.getIndexForOffset(scrollOffset, 'end'). Здесь важно заметить, что мы страницу считаем видимой, если видна ее нижняя граница, поэтому мы используем режим ‘end’  в методе getIndexForOffset. Текущий индекс страницы высчитывается иначе: мы считаем страницу текущей, если ее нижняя граница ниже половины видимой области. Сама пропорция относительно вьюпорта устанавливается константой const INDEX_CHANGE_VIEWPORT_PROPORTION: number = 0.5;. Так, например, если установить это значение в 0.7, то текущая страница будет та, у которой нижняя граница меньше 70% видимой области. Относительно видимого слайса данных, мы также имеем страницы которые находятся в буфферной зоне. Для понимания границ этой зоны сверху и снизу относительно позиции скроллбара мы вычитываем оффсеты startBufferOffset и endBufferOffset. Когда при прокрутке у нас смещаются эти границы, если нам достаточно места, то мы обновляем возвращаемый слайс. Само обновление происходит в функции update, которая забирает данные из замыкания. Здесь нам необходимо обновить отрендеренный диапазон данных, отступ сверху до контента, передать индекс текущей страницы, а также обнулить переданный стартовый индекс, чтобы он участвовал в вычислениях лишь в первый раз. Если вы рассчитываете повторить мой опыт, то вы должны быть в курсе режимов отображения документа. Обычно страницы отображают в исходных размерах, однако это может быть неудобно, когда документ содержит достаточное количество страниц формата А0, ведь их неудобно смотреть из-за больших размеров. Можно автоматически вычислить такой масштаб страниц, чтобы они точно влезли в область просмотра. Чтобы посчитать фактор квадрирования, необходимо знать размер видимой области, размер страницы и ее отступы по краям: Тогда новые размеры страницы можно вычислить, если их умножить на это значение. Есть два варианта, как применить квадрирование: Лишь к одной странице. Остальные страницы можно отмасштабировать относительно нее. Тогда мы будем точно гарантировать, что первая страница поместилась для любого размера вьюпорта, что полезно для адаптива. Обычно такой страницей выбирают либо первую, либо самую большую по размерам. К каждой странице. Тогда мы можем гарантировать, что все страницы помещаются во вьюпорт. Так как виртуальный скроллинг отрисовывает документ по слайсам, то при определенном масштабе появляется горизонтальный скролл. Однако, если при прокрутке подгружается страница большая по ширине, чем предыдущие, то документ может прыгнуть по горизонтали в пустое пространство. И тогда пользователь не поймет, что произошло. Чтобы избежать такого поведения, необходимо знать максимальную ширину документа. Это значение необходимо выставить скроллящемуся контейнеру, тогда у документа всегда верный горизонтальный скроллбар вне зависимости от текущего слайса. Максимальная ширина документа равна максимальной ширине страниц. Выставить это значение необходимо блоку с классом .cdk-virtual-scroll-content-wrapper, ведь именно он отвечает за скроллбары у контента. Сделать это можно через css-переменные: Здесь мы контейнеру выставили значение css-переменной через [style.--document-renderer-content__width.px]="maxWidthOfScrollingContainer$ | async", а на скроллящемся вьюпорте выставили класс document-renderer-scrolling-cdk-viewport. Тогда в глобальных стилях мы можем применить это значение Отдельные страницы документа могут весить достаточно много. К примеру, архитектурный план здания в масштабе страницы А0 в хорошем качестве может весить около 200мб. Можете представить, насколько долго будет загружаться такая страница. Однако зачем нам загружать сразу хорошее качество? И действительно, для демонстрации скроллинга это необязательно, ведь достаточно загрузить страницу лишь в том качестве, которое требует область просмотра. К примеру, если размеры вьюпорта 1600х900, то и изображение можно запросить с сервера с шириной 1600. Больше пикселей, чем это значение, все равно уместить не удастся. Конечно, можно подумать о ретина-экранах и грузить чуть больше — но это уже детали реализации. К тому же можно подумать о превью страниц в осознанно плохом качестве. Тогда они будут быстро отдаваться и можно будет быстро показывать контент пользователю. Реализовать это можно, если снабдить запрос параметром scale. Тогда scale: 1 будет отдавать изображение в оригинальных размерах, scale: 3 — увеличенное изображение в три раза, а scale: 0.05 — миниатюру страницы. Логика следующая: отправляем два запроса одновременно, превью отобразится быстро, а как только загрузится изображение лучше — необходимо будет переключить источник на него. Когда изображение рендерится, оно может вызывать перекомпоновку слоев, что вызовет блокировку скролла. Для ux это может быть критично. Чтобы избежать такого поведения, необходимо вынести каждую страницу в отдельный слой через свойство will-change: transform;. Тогда браузер будет манипулировать лишь им, и это не будет вызывать рекалькуляции всего скроллящегося контейнера. Когда размеры элементов предсказуемы или заранее известны, то кастомную стратегию виртуального скроллинга составить не вызовет особого труда, благодаря гибкости Angular CDK. Просмотрщик pdf-документа как раз тот вариант, когда это может потребоваться. Так что если перед вами стоит задача реализовать свой веб-реадер pdf, то теперь вы знаете, как создать максимально производительный скроллинг. Однако не забудьте учесть квадрирование, максимальные размеры документа, а также работу со слоями. Реализацию стратегии виртуального скроллинга для pdf-документов можно посмотреть здесь. В данном примере для имитации запросов к серверу используются интерсепторы. А также, чтобы не утяжелять демонстрацию, приводится работа лишь стратегии с примененным квадрированием к каждой странице без других дополнений, указанных в статье.  Frontend developer, tech lead