Pull to refresh

Comments 10

При этом держим в уме, что в общем случае сортировок мы стараемся избегать, и, как правило, пользователю они не нужны.

Невероятной степени сомнительности заявление. В моем опыте — наоборот, в каждом кейсе, где бизнес по каким-то причинам хотел вываливать юзеру кучу данных без фильтрации — бизнесу хотелось крутейшей сортировки хоть по всем полям сразу, с мотивацией примерно такого рода — дескать, фильтрация это для умных и для шарящих (нужно знать, что ты хочешь найти), а для тупых пускай будет сортировка, чтоб они потыкали в стрелочки сортировки так и сяк, и увидели, что вообще есть.

Не надо сортировку только в тех случаях, когда порядок записей имеет принципиальное значение. Так, вываливая строчки лога, навряд ли кто-то захочет их сортировать.

Я часто хочу: иногда первые записи нужны, иногда последние

Так это реверс, а не сортировка. Хотя для БДшников это конечно очень похожие яйца.

Я с точки зрения пользователя.

Нужно учитывать вводные. Речь в большей части идёт об оперативных хранилищах. Это раз. Во-вторых, селективный фильтрующий предикат жизненно необходим, иначе окно с рабочими данными будет со временем только расширяться, и система обречена.
Под фразой «как правило, пользователю они не нужны» я подразумеваю, что с требованиями бизнеса нужно работать и объяснять стоимость этих требований. Альтернативы просты: куча денег на железо и обречённость системы в перспективе или работа с пользователями, обучение, ограничения в интерфейсе и решения, принуждающие пользователя использовать фильтрацию вместо сортировок, где это возможно, и становиться умным и шарящим. Наверное, правильнее бы звучало «как правило, пользователю они на самом деле не нужны».
А вот какой запрос должен получиться, если пользователь захочет (и ему позволить…) отсортировать имена по возрастанию, а фамилии – по убыванию? Очевидно, что операция над кортежем уже не может быть применена. Видимо, эта задачка скорее умозрительная.
Попробовал обобщить решение: habr.com/ru/company/tensor/blog/517920

Вопрос насчёт курсорной пагинации. Есть ли какое-то теоретическое обоснование тому, что берётся страница на 1 элемент больше и делается запрос id >= ? где? — "лишний" элемент. Ведь можно и с обычным размером страницы делать запрос вида id > ? где? — последний элемент обычной страницы, это кажется гораздо удобнее, так как не надо производить дополнительные манипуляции с лимитом и отрезанием этого лишнего элемента.


Именно такой пример приведён например в Shopify:
https://engineering.shopify.com/blogs/engineering/pagination-relative-cursors


Я тоже использую именно "строго больше", может быть я что-то упускаю?

Увеличенный размер страницы позволяет сразу относительно недорого (без дополнительного запроса) определить, имеется ли следующая (предыдущая) страница или пользователь долистал все записи до последней страницы.

Наверное, имелся в виду этот момент?

Спасибо за ответ, похоже невнимательно прочитал. В целом так и догадывался.
Наверно так удобнее в случае API с непрерывными страницами, если же требуется показывать кол-во страниц, а-ля джанго админ, то пожалуй удобнее "строго больше". Хотя не сильно сложно и убрать один лишний элемент)

Sign up to leave a comment.

Articles