Обновить

Комментарии 18

Еще ни одному ПО или дезигнеру не удалось меня заставить добавить в интерфейс кнопку «назад». Она уже есть в браузере. В любом. Битва продолжается)

Тут, наверно, зависит ещё от того, какой подход вы используете в разработке роутеров. У вас локально может быть один роутер, а внутри компонента - куча if ))

А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.

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

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

А про пример с Google - полностью согласен. Именно поэтому в моём компоненте есть fallbackRoute. Если истории нет - уходим туда, куда логично, а не ломаем ожидания. Так что кнопка не «вместо» браузерной, а «дополнительно» к ней, с чуть более умной логикой под конкретный интерфейс.

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

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

и что она всегда делает ровно тоже самое что нативная браузерная кнопка

Я как раз про нативную браузерную кнопку назад и писал, и да, она всегда делает ровно то, что должна.

В действительности же это далеко не всегда так

В действительности как раз все так. Браузерная кнопка назад имеет предсказуемое и стабильно поведение.

Спасибо за статью 👍

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

Сохранил ссылку для важных переговоров чтобы не объяснять в сотый раз почему все обстоит именно так.

Вам спасибо огромное за комментарий, очень приятно ))

Во время ревью у меня некоторые ребята просят доказательства, что мои замечания в коде не просто так оставлены. Приходится теперь статьи писать и скидывать во время ревью :)

Во время исследования мы столкнулись с обратным ожиданием у пользователей, если у элемента более сложная формулировка. В вариантах «Назад к списку Х» и «<- Список Х» люди после перехода к списку нажимали браузерную кнопку назад и ожидали вновь оказаться на странице детализации, а не провалиться ещё дальше в истории.

Было бы классно приводить живые примеры с «более сложная формулировка». А то так сложно понять. Всегда будут какие-то клиенты, которые будут думать, что интернет вот так должен работать, и с этим ничего не поделаешь. Правильнее тогда с ними провести работу и объяснить, почему и как работают переходы

вы о чем ?)

Если вы про router.push и router.back(), то в статье это описано с примерами. Если же вы хотели услышать более детальное раскрытие логики работы push и back, то зачем? Статья же не про описание логики js back и push . Статья больше раскрывает суть правильного использования кнопки назад

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

Упоминается ведь цикл перенаправлений. Его можно решить в том числе и заменой push на replace.

А можете, пожалуйста, привести примеры, когда вам понадобилось использовать replace вместо push? Может, я забыл использование данного кейса, но я не помню в своей практике ((

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

Лично я им пользовался раз-два и обчёлся. Знаю одно применение. Если пользователь перешёл со стороннего сайта, то router.back() - не вариант, и тут как раз можно воспользоваться replace. Стоит рассмотреть его в интерцепторе из статьи и заменить push там, где не предусмотрен возврат.

Ну тут надо рассматривать конкретные кейсы, я бы лучше использовал router.push. В моём кейсе как раз этот случай тоже обрабатывается в goBack последним else. Опять же повторюсь, что и ваш вариант можно рассмотреть, но для меня push лучше. Я не призываю вас и не хочу вызвать у вас негативную реакцию. А то уже страшно оставлять комментарии - люди набрасываются))

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации