Когда оставляют длинные "— ", уже кажется, что это ИИ ответ. Это только первая часть рефакторинга, показывает мысли Алекса, на что можно опереться при рефакторинге. Чтобы полноценно рассказать все этапы рефакторинга, нужно тогда писать уже несколько статей.
И то на каждую статью найдется человек, который скажет, что всё неверно и не так вы мыслите, а на самом деле вот так должно быть. Тут уж правда зависит от любителя поспорить))
Ну тут надо рассматривать конкретные кейсы, я бы лучше использовал router.push. В моём кейсе как раз этот случай тоже обрабатывается в goBack последним else. Опять же повторюсь, что и ваш вариант можно рассмотреть, но для меня push лучше. Я не призываю вас и не хочу вызвать у вас негативную реакцию. А то уже страшно оставлять комментарии - люди набрасываются))
Вообще можно отдельную тогда статью написать про это, буду благодарен, если накидаете различные кейсы и почему именно replace вам нужно было использовать в ваших практиках. Какие есть плюсы и минусы у данного кейса в ваших практиках?
А можете, пожалуйста, привести примеры, когда вам понадобилось использовать replace вместо push? Может, я забыл использование данного кейса, но я не помню в своей практике ((
Если вы про router.push и router.back(), то в статье это описано с примерами. Если же вы хотели услышать более детальное раскрытие логики работы push и back, то зачем? Статья же не про описание логики js back и push . Статья больше раскрывает суть правильного использования кнопки назад
Было бы классно приводить живые примеры с «более сложная формулировка». А то так сложно понять. Всегда будут какие-то клиенты, которые будут думать, что интернет вот так должен работать, и с этим ничего не поделаешь. Правильнее тогда с ними провести работу и объяснить, почему и как работают переходы
Вам спасибо огромное за комментарий, очень приятно ))
Во время ревью у меня некоторые ребята просят доказательства, что мои замечания в коде не просто так оставлены. Приходится теперь статьи писать и скидывать во время ревью :)
Вы правы в том, что кнопка браузера работает предсказуемо, и ею все умеют пользоваться. Но в веб-приложениях (особенно SPA) кнопка «Назад» в интерфейсе нужна не для дублирования браузерной - она решает другую задачу.
Во-первых, на мобильных устройствах (где браузерные кнопки часто скрыты/меняются) явный элемент управления повышает конверсию. Во-вторых, в сложных сценариях (модалки, вкладки, шаги оформления заказа) кнопка «Назад» может возвращать не в историю браузера, а на логический предыдущий шаг внутри интерфейса - это разные вещи. В-третьих, она даёт контроль над fallback-логикой: если пользователь пришёл по прямой ссылке, мы можем вернуть его не в пустоту, а на главную или в каталог.
А про пример с Google - полностью согласен. Именно поэтому в моём компоненте есть fallbackRoute. Если истории нет - уходим туда, куда логично, а не ломаем ожидания. Так что кнопка не «вместо» браузерной, а «дополнительно» к ней, с чуть более умной логикой под конкретный интерфейс.
Тут, наверно, зависит ещё от того, какой подход вы используете в разработке роутеров. У вас локально может быть один роутер, а внутри компонента - куча if ))
Спасибо за вопрос, это действительно рабочий и частый паттерн. Но у него есть обратная сторона, которая всплывает не на старте, а когда проект живёт дольше полугода или над ним работает больше одного человека.
Главная проблема подхода :class="styles['size-' + size]"- он рвёт статическую связь между шаблоном и <style>. Для человека это читаемо, но для всей экосистемы разработки эти классы становятся «невидимыми» до момента выполнения кода.
Что конкретно ломается: - Линтинг и поиск неиспользуемых классовstylelint, purgecss, eslint-plugin-vue и подобные инструменты работают на статическом анализе. Когда класс собирается динамически, линтер не видит его в шаблоне.
- Явность vs Магияbutton_size_l сразу читается как «модификатор размера у блока button». styles['size-' + size] требует лезть в JS-объект, смотреть маппинг и гадать, какие ключи вообще существуют. В команде из 3+ разработчиков это превращается в квест.
Динамические маппинги имеют полное право на жизнь: когда вы работаете с CSS-переменными, утилитарными фреймворками или когда стили действительно генерируются на лету. Но для компонентной UI-системы, где важна долгосрочная поддержка, явный :class с БЭМ-модификаторами выигрывает за счёт прозрачности для разрабов и инструментов.
Можно, просто проще было привести пример с button. Если вам необходимо реализовать специальную кнопку для аватара, то тут вообще можно несколько вариантов предложить:
на основе button.vue сделать avatar-button.vue;
понять, что значит avatar-button. Ну, например, это передача Icon и border-radius: 30px, тогда проще как будто отдельные классы сделать
Я тоже в свободное время глубоко копаю и React, и Vue, и последние наблюдения заставляют задуматься. В экосистеме React, например, до сих пор нет прямого аналога Quasar «всё в одном». С React Compiler тоже были шероховатости в пет-проектах: в связке с react-hook-form иногда ломался ререндер :(
Спасибо, такое объявление роутеров через объектную конфигурацию еще не видел, интересный подход)
Честно говоря, с проблемой пересечения имен сталкиваться не приходилось, так как роутеры у меня строго разделены по фича-модулям. Плюс придерживаюсь правила: префикс name всегда беру из названия файла/папки (например, UserList, UserProfile в модуле User)
Я просто захотел написать статью - я её написал. Что я не так сделал? Что мне теперь, нельзя выкладывать статью, если я вот так захотел?
Извините, я с вами спорить не буду продолжать. Если вы так считаете, то это ваше право. Будьте чуть подобрее, пожалуйста, в комментариях!
А так истина зависит от проекта и от текущих требований. К сожалению, нет одного правильного ответа: вот так хорошо, а вот так плохо))
Есть инетерсная статья про стор: https://habr.com/ru/articles/1020074/
Когда оставляют длинные "— ", уже кажется, что это ИИ ответ. Это только первая часть рефакторинга, показывает мысли Алекса, на что можно опереться при рефакторинге. Чтобы полноценно рассказать все этапы рефакторинга, нужно тогда писать уже несколько статей.
И то на каждую статью найдется человек, который скажет, что всё неверно и не так вы мыслите, а на самом деле вот так должно быть. Тут уж правда зависит от любителя поспорить))
Наверно, не совсем корректное сравнение сделал в статье (
обещали еще одну грамоту подарить))
Ну тут надо рассматривать конкретные кейсы, я бы лучше использовал router.push. В моём кейсе как раз этот случай тоже обрабатывается в goBack последним else. Опять же повторюсь, что и ваш вариант можно рассмотреть, но для меня push лучше. Я не призываю вас и не хочу вызвать у вас негативную реакцию. А то уже страшно оставлять комментарии - люди набрасываются))
Вообще можно отдельную тогда статью написать про это, буду благодарен, если накидаете различные кейсы и почему именно replace вам нужно было использовать в ваших практиках. Какие есть плюсы и минусы у данного кейса в ваших практиках?
А можете, пожалуйста, привести примеры, когда вам понадобилось использовать replace вместо push? Может, я забыл использование данного кейса, но я не помню в своей практике ((
Если вы про
router.pushиrouter.back(), то в статье это описано с примерами. Если же вы хотели услышать более детальное раскрытие логики работыpushиback, то зачем? Статья же не про описание логики jsbackиpush. Статья больше раскрывает суть правильного использования кнопки назадвы о чем ?)
Было бы классно приводить живые примеры с «более сложная формулировка». А то так сложно понять. Всегда будут какие-то клиенты, которые будут думать, что интернет вот так должен работать, и с этим ничего не поделаешь. Правильнее тогда с ними провести работу и объяснить, почему и как работают переходы
Вам спасибо огромное за комментарий, очень приятно ))
Во время ревью у меня некоторые ребята просят доказательства, что мои замечания в коде не просто так оставлены. Приходится теперь статьи писать и скидывать во время ревью :)
Вы правы в том, что кнопка браузера работает предсказуемо, и ею все умеют пользоваться. Но в веб-приложениях (особенно SPA) кнопка «Назад» в интерфейсе нужна не для дублирования браузерной - она решает другую задачу.
Во-первых, на мобильных устройствах (где браузерные кнопки часто скрыты/меняются) явный элемент управления повышает конверсию. Во-вторых, в сложных сценариях (модалки, вкладки, шаги оформления заказа) кнопка «Назад» может возвращать не в историю браузера, а на логический предыдущий шаг внутри интерфейса - это разные вещи. В-третьих, она даёт контроль над fallback-логикой: если пользователь пришёл по прямой ссылке, мы можем вернуть его не в пустоту, а на главную или в каталог.
А про пример с Google - полностью согласен. Именно поэтому в моём компоненте есть
fallbackRoute. Если истории нет - уходим туда, куда логично, а не ломаем ожидания. Так что кнопка не «вместо» браузерной, а «дополнительно» к ней, с чуть более умной логикой под конкретный интерфейс.Тут, наверно, зависит ещё от того, какой подход вы используете в разработке роутеров. У вас локально может быть один роутер, а внутри компонента - куча if ))
Спасибо за вопрос, это действительно рабочий и частый паттерн. Но у него есть обратная сторона, которая всплывает не на старте, а когда проект живёт дольше полугода или над ним работает больше одного человека.
Главная проблема подхода
:class="styles['size-' + size]"- он рвёт статическую связь между шаблоном и<style>. Для человека это читаемо, но для всей экосистемы разработки эти классы становятся «невидимыми» до момента выполнения кода.Что конкретно ломается:
- Линтинг и поиск неиспользуемых классов
stylelint,purgecss,eslint-plugin-vueи подобные инструменты работают на статическом анализе. Когда класс собирается динамически, линтер не видит его в шаблоне.- Явность vs Магия
button_size_lсразу читается как «модификатор размера у блока button».styles['size-' + size]требует лезть в JS-объект, смотреть маппинг и гадать, какие ключи вообще существуют. В команде из 3+ разработчиков это превращается в квест.Динамические маппинги имеют полное право на жизнь: когда вы работаете с CSS-переменными, утилитарными фреймворками или когда стили действительно генерируются на лету. Но для компонентной UI-системы, где важна долгосрочная поддержка, явный
:classс БЭМ-модификаторами выигрывает за счёт прозрачности для разрабов и инструментов.Можно, просто проще было привести пример с button. Если вам необходимо реализовать специальную кнопку для аватара, то тут вообще можно несколько вариантов предложить:
на основе button.vue сделать avatar-button.vue;
понять, что значит avatar-button. Ну, например, это передача Icon и border-radius: 30px, тогда проще как будто отдельные классы сделать
Понимаю))
Я тоже в свободное время глубоко копаю и React, и Vue, и последние наблюдения заставляют задуматься. В экосистеме React, например, до сих пор нет прямого аналога Quasar «всё в одном». С React Compiler тоже были шероховатости в пет-проектах: в связке с
react-hook-formиногда ломался ререндер :(Спасибо, такое объявление роутеров через объектную конфигурацию еще не видел, интересный подход)
Честно говоря, с проблемой пересечения имен сталкиваться не приходилось, так как роутеры у меня строго разделены по фича-модулям. Плюс придерживаюсь правила: префикс
nameвсегда беру из названия файла/папки (например,UserList,UserProfileв модулеUser)user.routes.ts
Крик, но уже переходящий в хрип)