Почему я написал Paginator вместо Paging 3

В сфере искусственного интеллекта произошло заметное событие. Jamal_Aliev 1 минуту назад Почему я написал Paginator вместо Paging 3 Уровень сложности Простой Время на прочтение 7 мин Охват и читатели 0 Kotlin * Android * Мнение Это статья от автора библиотеки, поэтому нейтральным разбор не будет. Но это и не рассказ про конкретный проект — а разбор задач, на которых, на мой взгляд, Paging 3 начинает буксовать, и того, как Paginator устроен, чтобы эти задачи закрывать. KMP-библиотека пагинации для Android, iOS, JVM и Desktop.

Ниже — почему она появилась именно как отдельная библиотека, а не как fork или обёртка над Paging 3. Сцена, в которой Paging 3 перестаёт быть удобным Возьмите список требований, которые рано или поздно прилетают в любую ленту, чат или поисковую выдачу — обычно не на старте, а через несколько месяцев работы продукта: — открыть переписку (или ленту, или результаты поиска) на конкретном элементе по deeplink из push; — дать поставить лайк или отметить «прочитано» так, чтобы изменился ровно один элемент, без рефреша всего списка и без визуального мерцания; — после убийства процесса вернуть пользователя ровно туда, где он был, со всем видимым контекстом , а не на первую страницу; — добавить стрелку «к самому новому» или «к закладке» с прыжком в произвольное место ленты; — то же самое, пожалуйста, на iOS. В каждом из этих пунктов по отдельности Paging 3 не сдаётся — есть RemoteMediator , есть cachedIn , есть способы выкрутиться.

Технические детали

Но если они приходят пакетом — а в современном продукте они приходят пакетом, — выкручивание занимает больше времени, чем сама фича. И в какой-то момент команда замечает, что больше думает о том, как заставить PagingSource адресовать страницу, а не ключ, чем о том, как должен вести себя экран. С этого момента Paging 3 уже не инструмент, а ограничение, к которому подгоняется задача.

Это плохой знак — и именно ту точку, в которой он наступает, я и пытался отодвинуть, проектируя Paginator. Где Paging 3 начинает проседать Я не считаю Paging 3 плохой библиотекой — у неё хорошее ядро для конкретного класса задач. Но это ядро устроено вокруг определённых решений, и эти решения упираются в потолок раньше, чем хотелось бы.

Конкретно — в четырёх местах. PagingSource адресует ключами, а не страницами. Это разумно, когда лента листается курсорами вперёд-назад и неважно, какой по счёту элемент.

Отраслевые последствия

Но как только в задаче появляется «открой страницу с сообщением msg_817 » — оказывается, что прыгнуть можно только в страницу, ключ которой уже знаком. Канонический ответ — Room как источник правды и RemoteMediator , который синхронизирует БД с сетью. Для проектов, где БД и так есть, это нормально.

Если её нет, появление БД приходится обосновывать только ради того, чтобы пагинация работала. Это перевернутая зависимость: продуктовый сценарий начинает диктовать архитектуру слоя данных. PagingData иммутабельна и заточена под UI.

Когда задача требует поменять один элемент в ленте — поставить лайк, обновить статус «прочитано», локально удалить — прямого пути нет.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.