Пагинация в LoopBack 3
При разработке приложения с бэкэндом LoopBack обычно не занимает много времени, пока вам не понадобится какая-то разбивка на страницы в вашем интерфейсе, чтобы сделать длинные списки бесчисленных элементов более удобными для навигации.
К счастью, в LoopBack есть фильтр пропуска и фильтр ограничения, который позволяет нам реализовать разбиение на страницы, просто используя некоторые параметры URL. Ваш первый запрос на получение списка будет содержать
?filter={“skip”:0,”limit”:10}
следующий запрос
?filter={“skip”:10,”limit”:10}
и так далее. Это очень полезно!
Однако независимо от того, создаете ли вы классическую разбивку на страницы со страницами, кнопку Загрузить еще или даже какую-то бесконечную прокрутку, вам может потребоваться точно знать, сколько страниц или сколько элементов осталось для выборки. В этом посте я рассмотрю два варианта решения этой проблемы: заголовок X-Total-Count и миксин loopback-paginator.
Заголовок X-Total-Count
Как подсказывает заголовок, одним из решений было бы добавить заголовок к вашему ответу, который сообщает вам, сколько всего элементов. Это легко сделать с помощью следующего загрузочного скрипта, который вам просто нужно поместить в каталог server/boot.
Это автоматически перехватит все вызовы списков элементов (поиск) и добавит в ответ заголовок X-Total-Count. При этом также учитываются фильтры. Поэтому, если вы применили фильтр where к вашему запросу, будут учитываться только те элементы, которые соответствуют вашему фильтру.
В вашем интерфейсе вы можете использовать это общее количество, чтобы, например, рассчитать количество доступных страниц или скрыть кнопку загрузки, если больше нет доступных элементов.
Пагинатор обратной петли
Второй вариант - использовать миксин loopback-paginator. (Полное раскрытие: я являюсь автором этого миксина, который я написал, чтобы иметь, на мой взгляд, более элегантное решение проблемы разбивки на страницы.) После установки и применения миксина к вашим моделям (проверьте readme, чтобы увидеть все доступные параметры ), тело ответа ваших запросов GET / api / items будет выглядеть немного иначе:
Вместо массива со всеми вашими элементами тело будет содержать данные и мета. Данные содержат массив элементов, к которому вы привыкли, а мета содержит некоторую полезную информацию для реализации разбивки на страницы. Вы увидите общее количество элементов, общее количество доступных страниц, количество элементов на странице, а также текущую, предыдущую и следующую страницу (если есть). Это решение также учитывает все применяемые вами фильтры.
Я только начал работать над пагинатором на прошлой неделе, но у меня есть еще несколько функций, и скоро появятся обновления.
Итак, какое решение вы хотите использовать, зависит только от вас. Оба они оптимизируют взаимодействие с пользователем вашего приложения.
Есть вопросы? Хочешь сообщить мне, что ты думаешь? Просто оставьте комментарий ниже!
