Позиция на предыдущем экране не сохраняется при возврате

[SantjagoCorkez]

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

Шаги для повторения бага

1. Открыть список новостей или статей
2. Открыть комментарии у новости или статьи, имеющей большое их количество
3. Отмотать в самый низ списка комментариев
4. Вернуться по истории назад к списку новостей или статей

Ожидаемый результат
Возврат будет произведен в ту же позицию предыдущего экрана, с которой был совершен переход

Информация об устройстве:

• OS: Linux
• Браузер: Chromium
• Версия браузера: 90.0.4430.212

Комментарий
Вполне возможно, в breadcrumbs стоило бы добавить обработчик, который при переходе на связанный view добавлял бы anchor в тело entity, из которой произведен click-переход. Например, в заголовок этой entity. А по возврату этот же breadcrumbs выполнял бы scrollTo, после чего удалял бы этот anchor. Возможно, существуют и иные способы сохранить позицию скролла предыдущего view.

[jarvis394]

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

Например, на странице со списком статей сначала рендерятся блоки placeholder'ов, у который стандартная высота (допустим, 200 пикселей). Потом клиент получает данные с API и рендерит основной компонент PostItem, у которого (из-за текста заголовка) отличное от дефолтного значение высоты (допустим, 400 пикселей).

Следовательно, при возврате обратно со страницы комментариев, код пытается восстановить скролл с уже загруженными статьями (а на странице ещё плейсхолдеры с меньшей высотой).

Самое прикольное то, что я делал много фиксов на эту тему и до сих пор вся лента понемногу съезжает при смене view. Честно, не знаю в чём проблема. Надо подумать.

[SantjagoCorkez]

Возможно, там как-то надо event-колбек вешать на post-render? Ну и схема с anchor, наверное, должна сработать. Потому как scrollTo - вроде как стандартная браузерная фишка, работает как часы, а сломанные браузеры в расчет можно не брать.

[jarvis394]

У использования scrollTo есть большая проблема: при его вызове у клиента страница "дёргается", т.е. сначала рисуется изначальное положение, а потом то, которое передано в scrollTo. Это не очень красиво 😓

Поэтому я больше надеюсь на стандартную поддержку состояния скролла у браузеров (например, использую history.back где это возможно, т.к. оно сохраняет скролл)

[SantjagoCorkez]

Ну вот оно, очевидно, не работает. Тем более, страница рендерится при возврате заново сначала с плейсхолдерами (и, видимо, в этот момент, происходит scroll из истории), а потом рендерится заново уже с контентом. Возможно, стоит немного поступиться моментом статичности страницы в пользу UX, по возможности, добавив плавный эффект скролла?

[centralhardware]

Может делать возрат не к позиции скрола а к конкретной статье?

[jarvis394]

Я потихоньку начинаю переходить на SSR и Next.JS, одновременно проводя рефакторинг когда; в задачах как раз сделать нормальную навигацию между страницами в приложении.

стоит немного поступиться моментом статичности страницы в пользу UX, по возможности, добавив плавный эффект скролла?

А вы пробовали таким пользоваться?) Обычно, когда переходишь на какой-то экран, пользователь ожидает интеракции с контентом сразу же, как только этот контент появился/загрузился. Тут получается, что юзер переходит назад, пытается проскроллить, а его сайт пытается передвинуть на сохранённую ранее позицию.

Я думаю нужно развить тему сохранения размеров блоков после загрузки контента. Сейчас контент в ленте сдвигается на совсем немного (вроде как), поэтому, скорее всего, это какой-то мелкий баг в расчётах.

[SantjagoCorkez]

А вы пробовали таким пользоваться?) Обычно, когда переходишь на какой-то экран, пользователь ожидает интеракции с контентом сразу же, как только этот контент появился/загрузился. Тут получается, что юзер переходит назад, пытается проскроллить, а его сайт пытается передвинуть на сохранённую ранее позицию.

Переходя назад, пользователь ожидает вернуться туда, откуда уходил. Поэтому пользоваться сейчас пользователь "сразу" всё равно не может. Его возвращает в произвольное место предыдущей страницы. Дабы пользователю не мешало "скроллить", можно на время работы scrollTo подавлять события scroll от пользователя.

Сейчас контент в ленте сдвигается на совсем немного (вроде как), поэтому, скорее всего, это какой-то мелкий баг в расчётах.

У меня доходило до сдвига на как минимум пять блоков с новостью/статьёй вниз, если возвращаться из подвала комментариев или конца очень длинной статьи.