Комментарии 18
Еще ни одному ПО или дезигнеру не удалось меня заставить добавить в интерфейс кнопку «назад». Она уже есть в браузере. В любом. Битва продолжается)
Тут, наверно, зависит ещё от того, какой подход вы используете в разработке роутеров. У вас локально может быть один роутер, а внутри компонента - куча if ))
А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.
Вы правы в том, что кнопка браузера работает предсказуемо, и ею все умеют пользоваться. Но в веб-приложениях (особенно SPA) кнопка «Назад» в интерфейсе нужна не для дублирования браузерной - она решает другую задачу.
Во-первых, на мобильных устройствах (где браузерные кнопки часто скрыты/меняются) явный элемент управления повышает конверсию. Во-вторых, в сложных сценариях (модалки, вкладки, шаги оформления заказа) кнопка «Назад» может возвращать не в историю браузера, а на логический предыдущий шаг внутри интерфейса - это разные вещи. В-третьих, она даёт контроль над fallback-логикой: если пользователь пришёл по прямой ссылке, мы можем вернуть его не в пустоту, а на главную или в каталог.
А про пример с Google - полностью согласен. Именно поэтому в моём компоненте есть fallbackRoute. Если истории нет - уходим туда, куда логично, а не ломаем ожидания. Так что кнопка не «вместо» браузерной, а «дополнительно» к ней, с чуть более умной логикой под конкретный интерфейс.
Вы исходите из мысли, что все пользователи умеют ей пользоваться и что она всегда делает ровно тоже самое что нативная браузерная кнопка.
В действительности же это далеко не всегда так, поэтому дизайнеры ее любят и будут продолжать любить.
и что она всегда делает ровно тоже самое что нативная браузерная кнопка
Я как раз про нативную браузерную кнопку назад и писал, и да, она всегда делает ровно то, что должна.
В действительности же это далеко не всегда так
В действительности как раз все так. Браузерная кнопка назад имеет предсказуемое и стабильно поведение.
Спасибо за статью 👍
Везде где есть такая кнопка с ней одни и те же проблемы как под копирку и каждый раз все удивлены, что не все так просто.
Сохранил ссылку для важных переговоров чтобы не объяснять в сотый раз почему все обстоит именно так.
Во время исследования мы столкнулись с обратным ожиданием у пользователей, если у элемента более сложная формулировка. В вариантах «Назад к списку Х» и «<- Список Х» люди после перехода к списку нажимали браузерную кнопку назад и ожидали вновь оказаться на странице детализации, а не провалиться ещё дальше в истории.
Было бы классно приводить живые примеры с «более сложная формулировка». А то так сложно понять. Всегда будут какие-то клиенты, которые будут думать, что интернет вот так должен работать, и с этим ничего не поделаешь. Правильнее тогда с ними провести работу и объяснить, почему и как работают переходы
Использование replace не раскрыто
вы о чем ?)
Если вы про router.push и router.back(), то в статье это описано с примерами. Если же вы хотели услышать более детальное раскрытие логики работы push и back, то зачем? Статья же не про описание логики js back и push . Статья больше раскрывает суть правильного использования кнопки назад
детально раскрыта кнопка назад, и даже интерцепторы из роутера используются. При этом про replace не упоминается, как будто под него кейсов не существует.
Упоминается ведь цикл перенаправлений. Его можно решить в том числе и заменой push на replace.
А можете, пожалуйста, привести примеры, когда вам понадобилось использовать replace вместо push? Может, я забыл использование данного кейса, но я не помню в своей практике ((
Вообще можно отдельную тогда статью написать про это, буду благодарен, если накидаете различные кейсы и почему именно replace вам нужно было использовать в ваших практиках. Какие есть плюсы и минусы у данного кейса в ваших практиках?
Лично я им пользовался раз-два и обчёлся. Знаю одно применение. Если пользователь перешёл со стороннего сайта, то router.back() - не вариант, и тут как раз можно воспользоваться replace. Стоит рассмотреть его в интерцепторе из статьи и заменить push там, где не предусмотрен возврат.
Ну тут надо рассматривать конкретные кейсы, я бы лучше использовал router.push. В моём кейсе как раз этот случай тоже обрабатывается в goBack последним else. Опять же повторюсь, что и ваш вариант можно рассмотреть, но для меня push лучше. Я не призываю вас и не хочу вызвать у вас негативную реакцию. А то уже страшно оставлять комментарии - люди набрасываются))

Как правильно реализовать кнопку «Назад» во Vue: просто о сложном