Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг?
Какую это даёт выгоду серверу? Как-то ускоряет разработку?
Здравствуйте, ononim, Вы писали:
O>может тебе еще неудобно когда пишут время в форме 'вчера' 'позавчера' 'в среду' 'две недели назад' вместо этих непривычных гуманитарному складу ума дат.
Нет, это не "неудобно". Это реально бесит так, что аж трясёт. Главное — я не понимаю зачем так делают. Единственное объяснение — программист решил похвалиться, что он сумел сделать такую сложную работу, как вычитание дат.
O>может тебе еще неудобно когда пишут время в форме 'вчера' 'позавчера' 'в среду' 'две недели назад' вместо этих непривычных гуманитарному складу ума дат.
Вот это кстати тоже неудобно. Потому что страница может быть открыта например несколько дней назад.
На RSDN кстати тоже встречается — в описании опросов.
IMHO самый правильный подход — писать обоими способами (дата в скобках).
Здравствуйте, ononim, Вы писали:
M>>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО! O>может тебе еще неудобно когда пишут время в форме 'вчера' 'позавчера' 'в среду' 'две недели назад' вместо этих непривычных гуманитарному складу ума дат.
на ютюбе пишут "год назад". Причем 365+364 дня — это у них тоже год назад. Реально получается что "год назад" это от одного до двух лет назад
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг? M>Какую это даёт выгоду серверу? Как-то ускоряет разработку?
M>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО!
Вообще все эти аджаксы, превращающие сайты в SPA, порядком бесят, потому что ломают нормальную навигацию.
Такой вывод нельзя в избранное добавить.
U>мне как юзеру удобно. к примеру список товаров смотришь удобнее если продолжается, чем тыкать по страницам.
Это зависит от количества товаров.
Если их например 50 (5 страниц по 10 товаров), то объединить их в одну большую страницу по 50 товаров может быть вполне и удобнее, чем смотреть 5 страниц.
Например Find in page сразу по всей выборке работает.
А вот если 500 (50 страниц по 10), то в одну страницу их объединять уже не стоит и постраничность тут нужна и полезна.
Про бОльшие объёмы я и не говорю.
Самые неудобные примеры:
— VK: прокручиваешь wall posts группы на пару месяцев назад, а потом случайно попадаешь мышью на огромное поле сбоку и тебя перекидывает в начало
— Google.
Здравствуйте, vsb, Вы писали:
vsb>Что именно тебе неудобно?
Скроллирую, читаю, и тут хренак — конец списка больше не конец, а там ещё тонна. Если пункты в выдаче отличаются несильно (например, "usb charger" на ali) и левым глазом читаю чат, то легко потерять на каком я остановился. И, как правило, для такого товара мне хватит первой страницы, мне вторая вообще не нужна. Но я не могу прыгать по странице в начало и в конец, выбирая зарядник, потому конца то нет — прыжок в конец страницы будет означать новый результат.
Здравствуйте, пффф, Вы писали:
П>Как ты это узнал?
Прикинь, мне потребовались годы чтобы это понять... ооо, а как эти прыжки вверх бесили-то до этого. Зато теперь я вконтактный спец!
Ну и ты тоже теперь знаешь великую тайну
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг?
Столько комментариев, и хоть бы кто написал про keyset pagination в противоположность limit-offset.
Но разумеется, keyset pagination не противоречит разбиению результата на отдельные страницы, в противоположность бесконечному росту одной страницы, и бесконечный рост делают там, где плевать хотели на удобство пользователей.
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг? M>Какую это даёт выгоду серверу? Как-то ускоряет разработку?
Это связано с изменением парадигмы обмена информацией. Если ранее деды пытались что-то там систематизировать, можно было знать сколько страниц (примерно оценить объем), пытались разделять по темам. То современная парадигма — ПОТРЕБЛЕНИЕ. Информации условно бесконечно много (за всю жизнь не пересмотришь) и ты можешь потреблять ее сколько хочешь, пока не надоест. Подход к систематизации так же изменился.
Здравствуйте, m2user, Вы писали:
O>>может тебе еще неудобно когда пишут время в форме 'вчера' 'позавчера' 'в среду' 'две недели назад' вместо этих непривычных гуманитарному складу ума дат.
M>Вот это кстати тоже неудобно.
Особенно неудобно, когда чей-нибудь пост картинкой выкладывают, а там вместо даты "Вчера". Сколько бы лет ни прошло, дата на картинке уже не поменяется
Здравствуйте, Stanislaw K, Вы писали:
SK>Да, потому что разрабатывается только одна версия сайта — для мобильных устройств.
На мобиле бесконечная прокрутка еще и больше раздражает. Один-два экрана проскроллить — нормально, но больше — это уже издевательство даже хуже, чем на десктопе, потому что сложнее все время водить пальцем и легче промахнуться.
Здравствуйте, Michael7, Вы писали:
SK>>Да, потому что разрабатывается только одна версия сайта — для мобильных устройств.
M>На мобиле бесконечная прокрутка еще и больше раздражает. Один-два экрана проскроллить — нормально, но больше — это уже издевательство даже хуже, чем на десктопе, потому что сложнее все время водить пальцем и легче промахнуться.
Если тебя это успокоит:
Ты — не целевая аудитория.
Ты — уникальный.
ТЫ — мамонт, который не приносит дохода, и должен умереть вместе со своими десктопными привычками поросшими мхом.
Здравствуйте, wl., Вы писали:
M>>На мобиле бесконечная прокрутка еще и больше раздражает. Один-два экрана проскроллить — нормально, но больше — это уже издевательство даже хуже, чем на десктопе, потому что сложнее все время водить пальцем и легче промахнуться.
wl.>ели судить по приложению ВК, бесконечный скролл на мобилке как раз таки удобнее. Представь, что пришлось бы метить пальцем в номер следующей страницы, а палец покрывает сразу несколько ссылок с номерами страниц, и пришлось бы масштабировать страницу, чтобы уверенно попасть в цифру 2 "12345"
Крупная кнопка/ссылка перехода на первую страницу,
несколько (3-5) крупных кнопок/ссылок прямого перехода на предыдущие страницы от текущей,
крупная кнопка/ссылка перехода на минус одну от текущей
индикатор номера текущей страницы
крупная кнопка/ссылка перехода на плюс одну от текущей
несколько (3-5) крупных кнопок/ссылок прямого перехода на следующие страницы от текущей,
крупная кнопка/ссылка перехода на последнюю страницу.
на нескольких сайтах такое было, но пришли дизайнеры и сделали "как у всех". что характерно, после этого нормальные авторы и комментаторы пропали, контент тоже превратился в "как у всех".
Здравствуйте, undo75, Вы писали:
U>там кстати по умному сделано — не страницы, а ссылка "показать еще результаты" или типа того. и это добавляется в страницу ниже как продолжение...
...и хрен потом в этой бесконечной ленте найдешь то, к чему захотел вернуться.
Чем совершеннее технически средство, тем более примитивные, никчемные и бесполезные сведения при его помощи передаются.(с)Станислав Лем
LL>>...и хрен потом в этой бесконечной ленте найдешь то, к чему захотел вернуться.
U>контрол фэ
Чего контрол фэ? Вот у тебя лента, в ней 100500 аналогичных предложений. Они уже отобраны по контрол фэ. Тебе надо вернуться к одному из них. Как это сделать при бесконечной ленте? При страничной организации ты можешь знать, что оно было (допустим) пятым на 8-й странице. Здесь как быть?
Чем совершеннее технически средство, тем более примитивные, никчемные и бесполезные сведения при его помощи передаются.(с)Станислав Лем
M>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО!
может тебе еще неудобно когда пишут время в форме 'вчера' 'позавчера' 'в среду' 'две недели назад' вместо этих непривычных гуманитарному складу ума дат.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, Stanislaw K, Вы писали:
SK>>Да, потому что разрабатывается только одна версия сайта — для мобильных устройств.
M>На мобиле бесконечная прокрутка еще и больше раздражает. Один-два экрана проскроллить — нормально, но больше — это уже издевательство даже хуже, чем на десктопе, потому что сложнее все время водить пальцем и легче промахнуться.
ели судить по приложению ВК, бесконечный скролл на мобилке как раз таки удобнее. Представь, что пришлось бы метить пальцем в номер следующей страницы, а палец покрывает сразу несколько ссылок с номерами страниц, и пришлось бы масштабировать страницу, чтобы уверенно попасть в цифру 2 "12345"
M>Это зависит от количества товаров. M>Если их например 50 (5 страниц по 10 товаров), то объединить их в одну большую страницу по 50 товаров может быть вполне и удобнее, чем смотреть 5 страниц. M>Например Find in page сразу по всей выборке работает.
ну вот я например. периодически тарюсь в макси. пишу в поиске какие-нить "макароны". нафиг надо чтоб на несколько страниц?
там кстати по умному сделано — не страницы, а ссылка "показать еще результаты" или типа того. и это добавляется в страницу ниже как продолжение. на яплакал достаточно скроллировать и он подгружает. тоже не скажу, что неудачное решение
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг?
всяко есть. А автономная читалка FBReader позволяет оба способа чтения в любой момент. M>Какую это даёт выгоду серверу?
вкусы читателей
M>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО!
А другим юзерам удобно
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг? M>Какую это даёт выгоду серверу? Как-то ускоряет разработку?
Это удобней пользователю. Как раз постраничный вывод и нужен для уменьшения нагрузки на сервер. В идеальном мире с бесконечной производительностью ты всегда будешь получать полный список результатов поиска. Подгрузка результатов по мере скроллинга аппроксимирует этот идеальный мир.
M>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО!
Здравствуйте, Явь-истъ, Вы писали:
ЯИ>Вообще все эти аджаксы, превращающие сайты в SPA, порядком бесят, потому что ломают нормальную навигацию. ЯИ>Такой вывод нельзя в избранное добавить.
Даже с разбиением на страницы умудряются косячить. Например на сайтах с пополняемым контентом. Найдёшь в поисковике ссылку на нужную инфу на нужную страницу сайта, переходишь по ссылке на страницу с этим номером, а там уже этой инфы нет, её новая инфа вытолкнула на другую страницу.
U>кстати. я конечно не фронтендер, но чем это вредит серверу? что тыкнуть следующая страница, что событие на скроллинг. в чем разница?
Ну у бесконечного скрола часто нет события "предыдущая страница" или "страница с номером 18", что помогает несколько упростить запросы к базе, например.
Здравствуйте, aik, Вы писали:
vsb>>Что именно тебе неудобно?
aik>Скроллирую, читаю, и тут хренак — конец списка больше не конец, а там ещё тонна.
И чем это отличается от пейджинга в стиле 1 2 ... ?
aik> Если пункты в выдаче отличаются несильно (например, "usb charger" на ali) и левым глазом читаю чат, то легко потерять на каком я остановился. И, как правило, для такого товара мне хватит первой страницы, мне вторая вообще не нужна. Но я не могу прыгать по странице в начало и в конец, выбирая зарядник, потому конца то нет — прыжок в конец страницы будет означать новый результат.
Зачем прыгать по странице в конец? Я не понимаю. Я выбираю нужный мне критерий сортировки, иду сверху вниз, интересующие меня предметы открываю в новых вкладках и когда сочту, что для выбора мне достаточно вариантов — начинаю выбирать среди них.
Здравствуйте, vsb, Вы писали:
vsb>>>Что именно тебе неудобно? aik>>Скроллирую, читаю, и тут хренак — конец списка больше не конец, а там ещё тонна. vsb>И чем это отличается от пейджинга в стиле 1 2 ... ?
Тем, что 2, 3.... сами не откроются, пока не кликнешь.
vsb>Зачем прыгать по странице в конец? Я не понимаю. Я выбираю нужный мне критерий сортировки, иду сверху вниз, интересующие меня предметы открываю в новых вкладках и когда сочту, что для выбора мне достаточно вариантов — начинаю выбирать среди них.
Удобно когда несколько вариантов на одной странице, чем скакать по вкладкам. Мне не всегда нужны детали. Скакать по табам неудобно, а сплиттеры в браузерах почему то пропали.
Здравствуйте, Mihal9, Вы писали:
M>Скажите, а с чем связана эта модная тенденция на сайтах — вместо пагинации страниц делать бесконечный скроллинг?
Нет никакой выгоды. Просто современные веб-макаки просто слишком тупые, и пагинацию не осиливают.
M>Потому что мне как юзеру это РЕАЛЬНО НЕУДОБНО!
Покинул вконтакт 10 лет назад именно из-за того, что поиск старых записей/картинок (например, было что-то интересное в прошлом году) там совершенно невозможен. Нормальные для юзера варианты — либо страницы как в книге, либо древовидная структура.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
S>Ну у бесконечного скрола часто нет события "предыдущая страница" или "страница с номером 18", что помогает несколько упростить запросы к базе, например.
известно же насколько работает скролл. в чем принципиальная разница?
WX>Покинул вконтакт 10 лет назад именно из-за того, что поиск старых записей/картинок (например, было что-то интересное в прошлом году) там совершенно невозможен. Нормальные для юзера варианты — либо страницы как в книге, либо древовидная структура.
Если поиск по тексту, то он там есть, как по стартовым сообщениям, так и по комментам (в рамках записей группы или отдельного аккаунта).
Если же речь идет о навигации в прошлое, то согласен, очень неудобно.
U>ну вот я например. периодически тарюсь в макси. пишу в поиске какие-нить "макароны". нафиг надо чтоб на несколько страниц?
так, а я что написал? Если этих макаронов не больше, чем несколько десятков, то лично мне совершенно не принципиально одна там страница (сразу подгружаемая или динамически) или 2-3.
Проблемы начинается, когда результатов поиска на порядок больше, или вообще неизвестное число (как результат поиска в Google).
U>там кстати по умному сделано — не страницы, а ссылка "показать еще результаты" или типа того. и это добавляется в страницу ниже как продолжение. на яплакал достаточно скроллировать и он подгружает. тоже не скажу, что неудачное решение
Ну да, на приличных сайтах и страницы есть, и кнопка "показать ещё".
Здравствуйте, Worminator X, Вы писали:
WX>Покинул вконтакт 10 лет назад именно из-за того, что поиск старых записей/картинок (например, было что-то интересное в прошлом году) там совершенно невозможен. Нормальные для юзера варианты — либо страницы как в книге, либо древовидная структура.
твиттер кстати ещё хуже. Посты рандомные и всегда разные. Ещё и отсортированы не по дате
LL>Чего контрол фэ? Вот у тебя лента, в ней 100500 аналогичных предложений. Они уже отобраны по контрол фэ. Тебе надо вернуться к одному из них. Как это сделать при бесконечной ленте? При страничной организации ты можешь знать, что оно было (допустим) пятым на 8-й странице. Здесь как быть?
ну я про магазин макарон говорил ) сначала пишешь в поиске макфа. он вываливает. нажимаешь контрол-фэ спагетти.
естественно это решение для гроссбуха не подойдет. но добавив несколько фильтров — че бы и не?
Сегодня эта же дрянь (бесконечная прокрутка) вылезла на Озоне.
При подготовке минимально воспроизводимого примера, обнаружил, что для возврата постраничности результатов поиска достаточно почистить Cookie и Local/Session Storage.
Что это было
Здравствуйте, 777777w, Вы писали:
7>не понимаю зачем так делают.
На что-то оригинальное способна лишь малая доля всех дизайнеров/программистов. Остальные тупо передирают то, что в этом сезоне считается ходовым, по возможности добавляя что-то от себя.
Ладно бы еще у скролинга был скролбар... но нет. Видимо предполагается что юзер обязан пальцем (если на тачдевайсе) или колесом мыши (если на десктопе) проскролить все-все-все, не пропустив ничего.
Здравствуйте, m2user, Вы писали: M>- VK: прокручиваешь wall posts группы на пару месяцев назад, а потом случайно попадаешь мышью на огромное поле сбоку и тебя перекидывает в начало
а если тыкнешь туда еще раз то перекидывает обратно где был
Здравствуйте, m2user, Вы писали:
M>Сегодня эта же дрянь (бесконечная прокрутка) вылезла на Озоне. M>При подготовке минимально воспроизводимого примера, обнаружил, что для возврата постраничности результатов поиска достаточно почистить Cookie и Local/Session Storage. M>Что это было
у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой.
под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел.
S>Ну у бесконечного скрола часто нет события "предыдущая страница" или "страница с номером 18", что помогает несколько упростить запросы к базе, например.
запросы-то такого же вида с параметрами типа page_num=xxx&items_per_page=yyy, а внутри уже LIMIT к базе и OFFSET. Что в случае пагинация, что в случае с фетчем – одинаково. Так что скорее всего фронт сам подсчитывает все. Ну может кто-то делает и фетчем на сервер, но с токенов. И даже в таком случае запросы к базе те же, просто оффсет и лимит на стороне бэка считается. А если и кэшируется что-то из базы, то все-равно одинаково кешируется.
короче, не вижу никаких упрощений запросов к базе. если знаешь точные примеры — поделись, любопытно.
vsb>Это удобней пользователю. Как раз постраничный вывод и нужен для уменьшения нагрузки на сервер. В идеальном мире с бесконечной производительностью ты всегда будешь получать полный список результатов поиска. Подгрузка результатов по мере скроллинга аппроксимирует этот идеальный мир.
DP>запросы-то такого же вида с параметрами типа page_num=xxx&items_per_page=yyy, а внутри уже LIMIT к базе и OFFSET. Что в случае пагинация, что в случае с фетчем – одинаково. Так что скорее всего фронт сам подсчитывает все. Ну может кто-то делает и фетчем на сервер, но с токенов. И даже в таком случае запросы к базе те же, просто оффсет и лимит на стороне бэка считается. А если и кэшируется что-то из базы, то все-равно одинаково кешируется.
DP>короче, не вижу никаких упрощений запросов к базе. если знаешь точные примеры — поделись, любопытно.
сам уже понял: мы просто тем самым убираем с бэка АПИшку и в-принципе возможность навигации к произвольной странице, тем самым разгрузив сервер
тем не менее, все же основная причина, думаю, высказана коллегами в соседних ветках: UX и всякие показатели удержания пользователей + показ им нужно информации + привычное потребление информации в виде бесконечной ленты
Здравствуйте, qqqqq, Вы писали:
M>>- VK: прокручиваешь wall posts группы на пару месяцев назад, а потом случайно попадаешь мышью на огромное поле сбоку и тебя перекидывает в начало Q>а если тыкнешь туда еще раз то перекидывает обратно где был
SK>у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой.
хм, можешь привести ссылки на примеры разделов обоих видов?
В моем случае одномоментно во всех разделах пропали страницы.
Как уже писал, сброс куков и пр. локальных кешей исправил ситуацию.
Там где куки не сбрасывал до сих пор бесконечный скрол.
SK>под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел.
Да, есть такое, но это мелкая непрятность, каких там ещё немало: неверные единицы измерения (мм/см), пропадающие фильтры и пр.
Здравствуйте, m2user, Вы писали:
SK>>у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой. M>хм, можешь привести ссылки на примеры разделов обоих видов?
Затруднительно. я сразу так не припомню где именно, при каких условиях в озоне мне попадались ссылки в раздел с прокруткой. Там еще прикол в том, что другая ссылка на этот-же раздел показывает его постранично.
M>В моем случае одномоментно во всех разделах пропали страницы. M>Как уже писал, сброс куков и пр. локальных кешей исправил ситуацию. M>Там где куки не сбрасывал до сих пор бесконечный скрол.
Не, мне показывает то так, то эдак, без явной закономерности. если попадается прокрутка просто делаю шаг назад и перехожу еще раз.
SK>>под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел. M>Да, есть такое, но это мелкая непрятность, каких там ещё немало: неверные единицы измерения (мм/см),
это продавцы криво заполняют карточки.
M>пропадающие фильтры и пр.
Здравствуйте, qqqqq, Вы писали:
Q>Ладно бы еще у скролинга был скролбар... но нет. Видимо предполагается что юзер обязан пальцем (если на тачдевайсе) или колесом мыши (если на десктопе) проскролить все-все-все, не пропустив ничего.
Членом он это должен делать, членом. Во всяком случае, я бы разработчиков такого и их руководство (и собственников) именно так заставил бы скроллить.
Здравствуйте, DiPaolo, Вы писали:
vsb>>Это удобней пользователю. Как раз постраничный вывод и нужен для уменьшения нагрузки на сервер. В идеальном мире с бесконечной производительностью ты всегда будешь получать полный список результатов поиска. Подгрузка результатов по мере скроллинга аппроксимирует этот идеальный мир.
DP>каким образом? что там, что там – одинаковые запросы на сервер и к базе. вот подробнее расписал http://rsdn.org/forum/web/8842263.1
Первый это запрос по конкретной странице, как было указано — с limit и offset. Проблема этого запроса в том, что он каждый раз отрабатывает заново. Я извлекаю 1 страницу — ну ок, 100 записей извлеки. Я запрашиваю 2 страницу, извлекли 200 записей, первые 100 пропустили, вторые 100 отдали. Я запрашиваю 1000 страницу, 100 000 записей извлекли, 99 900 пропустили, последние 100 отдали. Это квадратичный алгоритм. Он нормально работает, когда пользователю типично нужна первая, иногда вторая страница, но если пользователь часто скроллит далеко (а это реальный юзкейс во всяких инстаграммах, где юзеры могут скроллить часами), это неприменимо.
В принципе этот подход можно оптимизировать, если сильно нужно, добавить в базу поле "страница", пересчитывать его при удалении чего-то и тд. Это довольно муторно, но иногда нужно. Но когда условие может быть произвольным (к примеру результаты поиска сообщений конкретного пользователя, или вообще по произвольному условию), то этот подход оптимизировать нельзя никак.
Второй подход: сначала делаем запрос id > 0 and {condition} order by id limit 100. Возвращаем результат. Для следующей страницы клиент передаёт максимальный id предыдущей страницы и мы делаем запрос id > {prev_id} and {condition} order by id limit 100. Эти запросы уже всегда отрабатывают эффективно (конечно при условии наличия индексов). Минус этого подхода в том, что невозможно перейти с первой страницы на сотую. Т.е. сделать интерфейс с номерами страниц, как на типичном форуме, будет затруднительно. Можно только с текущей страницы перейди на первую, последнюю, предыдущую и следующую. Но если мы реализуем подгрузку результатов по мере скроллинга, то нам как раз и не нужно переходить на произвольную страницу, как раз именно переход на следующую страницу (или на предыдущую или возврат на последнюю) это типичный юз-кейс.
