• Подкасты — самый простой способ повышения кругозора программиста
    0
    Подкасты — это простой и ненапряжный способ повышения кругозора

    Кругозора да. Но для освоения новой информации — подкасты самый невыгодный вариант по кпд.

    развивается человек или нет. Какие ресурсы он изучает. На какие митапы ходит.

    Чтобы быть максимально цельной личностью и приятным человеком — нужно развиваться всесторонне, а не только всё своё свободное время читать ресурсы, ходить на митапы и слушать подкасты. Т.е., например, чтение художественной литературы, курсы вождения, баскетбол по пятницам, путешествия, прокачка ораторских навыков или навыков продаж, изучение психологии, английский язык, пикап-тренинги, плейлист на ютубе как воспитывать детей, управление финансами и инвестиции, отдых с друзьями и хобби — это всё тоже развитие как для тела, так и для разума.
    Вот и получается что человек, который не забивает всё своё свободное время только профессиональными знаниями — по жизни может быть в несколько раз больше РАЗВИТ чем тот, который осваивает только профессиональные знания и навыки.

    Едешь с работы — включил подкаст.

    Никогда не понимал советов — типа использовать время в дороге с работы домой для чего-то полезного (типа там подкасты на английском и т.д.). Я обычно это время использую, чтоб отдохнуть, переключить контекст с работы на дом, дать глазам и мозгу отдохнуть не воспринимая никакую новую информацию, подумать о чём-то своём, позвонить кому-то.
    Т.е. когда до удалёнки все жаловались что жалко тратить час на дорогу — я не понимал… это ж не трата времени. Это наоборот время для возможности передохнуть морально и побыть наедине с собой, передышка и от работы И от семьи..) главное в дисплей не таращиться..)
  • Дата и время: трудно, но возможно
    0
    В этом докладе освещается возможное универсальное решение от «всех проблем» с датой.
  • REACT + JEST = TDD ❤️
    +1
    Эта методология разработки мотивирует в первую очередь подумать, а не приступить. Это позволяет глубже погрузиться в задачу и не упустить всевозможные корнер-кейсы.

    А без TDD и тестов разве не нужно сначала подумать и вникнуть в задачу, перед тем как писать код? Разве не нужно продумывать всевозможные эдж-кейсы?

    При test last подходе не нужно много думать — можно сразу переходить к написанию кода.

    А если подумать много заранее? получается можно обойтись без TDD?
    Т.е. получается какая разница где думать много — перед написанием кода, или перед написанием тестов? Всё-равно подумать много надо в любом случае. Получается TDD — лишнее звено?..)
  • Как заставить руководство проникнуться техническим долгом
    +2
    «Руководство не даёт мне заняться рефакторингом legacy-кода!»

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

    И даже когда пытаешься им объяснять, какие преимущества даёт опрятный код

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

    За рефакторинг никто платить не будет. Положение выглядит безнадёжным.

    Как на счёт такой стратегии?:
    Не говорить руководству про технический долг и рефакторинг… чтоб они даже слов таких не знали.

    Просто каждый раз при оценке абсолютно любой(!) задачи закладывать в озвученные сроки ещё ~200% времени. Т.е. когда просят добавить кнопочку — не бить себя в грудь и говорить что это плёвое дело на пару часов. А с покер-фейсом говорить что эта кнопочка займёт два дня (даже если там работы на пару часов).

    На вопросы — почему, ответ — потому что. Понятное дело что это должно идти от тим-лида и нужна определённая смелость. Но всё-таки технические моменты — рефакторинг, техдолг, выбор стека и т.д. — это не в области ответственности руководства, а в вашей (вас же для этого и наняли).

    Фишка в том, что руководство рано или поздно привыкнет к такой скорости. И в итоге по идее выиграют все. Для руководства — качество продукта будет выше, а для разработчиков уровень напряжения меньше.

    P.S. заметил что некоторые разрабы сами склонны занижать сроки, особенно публично… типа та что там делать… делов на пять минут. Толи повыпендриваться, толи страх показаться некомпетентными. Вместо того, чтобы наоборот нармально запаса заложить для подстраховки.
  • Рендеринг на клиенте, на сервере и генерация статических сайтов
    0
    Не нужно полностью перезагружать страницы
    Пользователи могут переходить по страницам без серии обращений к серверу. Из-за этого создаётся ощущение высокой скорости работы, почти как у нативного приложения.

    Какая разница где наблюдать спиннер… во вкладке браузера или в UI?

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

    Почему это считается недостатком? Ведь
    Сайт — одна или несколько логически связанных между собой веб-страниц.
    Логично что при переходе между страницами — будет рефреш браузера.
  • Мышление письмом
    +3
    Кстати забавно иногда выходит. Каждый раз когда кто-то прибегает или звонит с бесконечным потоком мыслей изо рта, посылаешь его нахер написать письмо на почту. В итоге письмо не приходит… оказывается он не учёл каких-то моментов, и пока не так уж и срочно надо..)
  • Как делать анимацию, которая нравится всем (даже пользователю)?
    0
    А как повысить производительность?

    Слышал ещё, что для свойств которые вызывают repaint /растеризацию (например color, opacity, какие-то тени, градиенты) изингами в анимациях лучше не увлекаться, а использовать линейный linear. Пользователь практически не заметит, а браузеру дышать будет легче.
  • Вы не знаете как должны работать модальные окна
    0
    Кстати, проверил (на Chrome/Android). Сейчас уже атрибут autofocus не вызывает автоматом клавиатуру пока не тапнешь по полю (хотя оно уже в фокусе). Хотя раньше это было. Видимо разработчики браузеров/OS и так к этому пришли..)
  • Вы не знаете как должны работать модальные окна
    0
    Просто на маленьких устройствах она занимает чуть ли не более 50% экрана. Минус статус-бары браузера и телефона, остаётся очень мало места, как раз для того одного инпута. И зачастую чтобы понять что от тебя хотят, нужно сначала убрать клавиатуру, окинуть взглядом всю форму, поскроллить туда-сюда при необходимости, и потом уже целенаправленно фокусироваться на нужном элементе.

    Это я к тому, что на таких тач-устройствах всё-таки автоматический фокус на поле ввода — скорее ухудшит UX, особенно заметно на мамах\бабушках. Оно реально пугает их. Т.е. пока ты ещё не понял что от тебя хотят, а уже что-то вводить нужно.
  • Вы не знаете как должны работать модальные окна
    +1
    В моей картине мира:

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

    Если модальное окно не является диалоговым, т.е. оно несёт новое содержание (форма там например, текст аферты и т.д.) — то по идее можно отдельный роут на него заводить и открывать ссылкой (если говорить про SPA). Т.е. вполне вероятен кейс, когда юзер захочет пошарить это содержимое с кем-то (отправить ему ссылку).
  • Вы не знаете как должны работать модальные окна
    0
    Во время открытия диалогового окна фокус должен быть перемещён на элемент внутри него.
    Например, для диалога с формой первый интерактивный элемент это первый input.

    Как бороться с автоматически всплывающей клавиатурой на тач-устройствах?
  • «Никогда не писали автотесты? Попробуйте Cypress»
    0
    программистов больше не надо бить палкой, чтобы они написали хоть парочку e2e-тестов

    При чём здесь программисты? А тестировщики тогда для чего?
  • Почему это антипаттерн?
    0
    подтверждаю, последние два года попадается только Mobx слава богу)
  • Введение в React, которого нам не хватало
    –1
    Этот материал написан для тех, кто хочет найти ответ на следующие вопросы: Почему React работает именно так?

    Хочу найти простое объяснение на вопрос про это:
    У каждого элемента списка, который нужно вывести, должен быть постоянный уникальный идентификатор, предназначенный для использования в JSX-атрибуте key.

    Почему сам React не добавляет этот key автоматически? Почему это должен делать разработчик?
  • Введение в React, которого нам не хватало
    0
    JSX — это спагетти в лучших традициях PHP

    Просто по факту React — это прокачанный шаблонизатор. Поэтому зависит от дисциплины разработчика. Заметил, что именно бекенд-разработчики с php-прошлым превращают JSX в спагетти, превращают разметку в кошмар..) Видите-ли негоже тру-фуллстеку думать над композицией компонентов, где надо разделить на компоненты, а где лучше всё вместе оставить)
  • JavaScript и TypeScript: 11 компактных конструкций, о которых стоит знать
    0
    9. Параметры функций, которые могут иметь значения, назначаемые по умолчанию


    Не забывайте указывать, что значения по умолчанию применяются только в двух случаях:
    — значение не передано;
    — передано значение undefined;
    Другими словами, если передать в функцию параметр null, 0, false, '' — то параметр по умолчанию не применится.
  • Micro-frontends. Асинхронный подход к мультикомандной разработке
    0
    то мы получим двойную загрузку необходимых библиотек, и соответственно, ухудшение метрик производительности.

    Подскажите, а блок peerDependencies в package.json не решал эту проблему?
  • Дружим Angular с Google
    0
    Даже крупнейшие магазины электронной коммерции по-прежнему выглядят как куча статических страниц, для пользователя это нескончаемый цикл кликов, ожидания и перезагрузки страниц.

    что в этом плохого? какая разница где наблюдать спиннер — во вкладке браузера или в UI?

    Мы любим JS и Angular. Мы верим, что классный и удобный UX может быть построен с на этом стеке технологий, и мы можем решить все сопутствующие проблемы.

    Делать интернет-магазин как SPA — это попахивает разводом заказчика на деньги.
    Основная ценность интернет-магазина — это фильтры/поиск и Карточка товара. Правильно свёрстанная семантически и со своим «серверным» урл-ом (название которого должен придумать сео-специалист). Т.е., да, фактически интерент магазин — это набор статических перелинкованных страничек. Что в этом плохого?

    Оставьте SPA для проектов — где основной ценностью является не контент, а взаимодействие и результат этого взаимодействия юзера и продукта (читай там где богатый пользовательский сценарий). Например, онлайн-фотошопы, олайн эксель-таблицы, всякие софт-фоны, игры, конструкторы, личные кабинеты, и т.д.

    Там где основная ценность контент — лендинги, магазины, блоги и т.д. — это всё в первую очередь про индексацию и статику… зачем там spa?
  • Отказ от create-react-app и создание собственного шаблона для React-приложений
    0
    спасибо, что поделились.

    Для меня вывод простой — если у вас большой и сложный проект, много своих хотелок, и достаточно бюджета времени на то чтобы сшить конфиг под свои нужды, тогда не заигрывайтесь с CRA. А сделав eject, просто выпиливайте его целиком.

    Хотелок не сильно много. Там декораты для mobx-а добавить, там svgo какой-нибудь прикрутить. Впринципе, полностью понимаем, что после eject-а мы сами по себе, и постепенно «заменяем» cra-шный конфиг своим по мере развития проекта.
    Но фишка в том, что в самом начале мы-то секономили кучу времени за счёт того, что другие (команда facebook или кто там разрабатывает cra) его потратили.
    Мы ведь не знаем на старте как дальше проект пойдёт, может и cra достаточно будет, а если не будет — пожалуйста eject. Я именно поэтому недоумевал — что плохого, чтоб сначала взять cra-конфиг секономив время, а потом допиливать его по мере развития проекта (после eject-а под свою ответственность понятное дело).
  • Отказ от create-react-app и создание собственного шаблона для React-приложений
    0
    спасибо.
  • Отказ от create-react-app и создание собственного шаблона для React-приложений
    0
    Давно ищё ответ на вопрос, почему мне нужно бояться команды eject? Что в этом плохого?
    Я воспринимаю cra — как отличный отдебаженный инструмент, который разрабатывают много хороших разработчиков. И это как стартовая настройка для проектов (типа prettier-а, чтоб не было разногласий в команде.). И если вдруг нужно что-то добавить/кастомизировать — делаем eject. Так вот в чём проблема eject-а? почему я не должен его делать?
  • Что, черт возьми, такое гидратация и регидратация?
    0
    Можно ещё просто отделять само приложение (SPA) и seo-чувствительные странички. При этом:
    SPA — делать по человечески, с клиентским рендерингом и без ssr-костылей.
    SEO-странички — делать классическим способом, т.е. генерацией серверных шаблонов на бекенде.

    Как правило, весь богатый ui функционал (всякие личные кабинеты, дашборды) спрятан за страничкой авторизации. Этот богатый ui-функционал, т.е. сам продукт, и не должен индексироваться.
    А вот сама страничка входа/авторизации, какие-то начальные странички/лендинги на основном сайте, которые описывают/рекламируют сам продукт, как раз таки должны индексироваться. Вот их можно делать на серверных шаблонах с jquery.
  • Локальное хранилище или куки? Безопасное хранение JWT на клиенте
    0
    Локальное хранилище уязвимо к XSS-атакам

    Почему всегда доступ из js в localStorage объявляют как минус? Ведь если на сайт УЖЕ прошла xss атака, т.е внедрили чужой js… то уже как бы поздно. Какая уже разница где хранятся токены. Наворотить уже можно что угодно по идее.
    Т.е. в контексте вопроса в статье, переживать необходимо про xss, а не о том где бы безопаснее токены хранить.
  • О конфликтах Sass и сравнительно новых возможностей CSS
    0
    Автор материала

    Прошу прощения. Автор наркоманка? или много свободного времени на работе?

    Главный вывод, который я могу сделать, получился таким

    Никогда не «программировать» в стилях! тем самым усложняя жизнь другим и нагружая процессор (особенно на мобилках).

    Можно создавать стикеры с границами (border), созданными с использованием необычных шаблонов. В данном примере стикер создаётся из единственного HTML-элемента, а шаблон, используемый для настройки border, создаётся с применением clip-path, циклов и математических вычислений в Sass. На самом деле, вычислений тут довольно много.

    Стили и разметка служат для вёрстки (!). Для картинок, иллюстраций или фото — есть соотетствующие теги — png, jpeg, svg (если нужен интерактив). Т.е. в данном случае нарисовать эти стикеры — это работа дизайнера, а не разработчика.

  • Борьба за производительность по-настоящему больших форм на React
    +1
    Нормально вроде уживаются вместе. Главное на забывать что в методе render компонента Form наблюдаемые значения не будут видны.
    Необходимо дополнительно оборачивать кусок разметки, нуждающийся в каком-то наблюдаемом значении, в observer (nesting-caveat).
  • Борьба за производительность по-настоящему больших форм на React
    0
    Использовал такой github.com/QuantumArt/mobx-form-validation-kit#doc_rus
    и final-form.
    Final-form + mobx — показалось идеальным для меня.
  • Как верстать веб-интерфейсы быстро, качественно и интересно
    0
    Я уже много лет занимаюсь, прежде всего, разметкой интерфейсов, их оформлением и поведением, экранами и GUI. Участвовал на позиции верстальщика в небольших командах, стартапах, а также реализовал некоторое количество проектов самостоятельно как фрилансер, дизайнер и верстальщик. За это время я накопил некоторый опыт по специфическим проблемам в данной области, которым мне очень хочется поделиться.

    Был ли у вас опыт переживания многочисленных редизайнов одного проекта на протяжении нескольких лет?
    Я к тому, насколько рекомендации в статье подходят к случаям, когда на проекте примерно раз в 8 месяцев разгоняется отдел маркетинга и нанимается новый? Когда меняются дизайнеры.
    Просто по опыту, в этом случае, все эти чрезмерные sass-абстракции превращаются в тыкву)
  • Видеозапись в облако своими руками
    0
    Открывать же браузер, а затем нажимать на значок домика (если вы установили написанное в качестве домашней страницы) довольно долго.
    Выход очень прост: создаем в файловой системе телефона простенький файлик alarm.html:

    Можно ещё оформить как pwa приложение.
  • Визуализация списка женщин-лауреатов Нобелевской премии в виде кристаллов в 3d с использованием Vue, WebGL, three.js
    +2
    с использованием Vue, WebGL, three.js

    А зачем в проекте vue? какую проблему он решал?
  • Состояние дел в сфере микрофронтендов
    +1
    Я так понимаю, без iframe все это сделано?

    Да

    А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2?

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

    И нельзя ли пример кода глянуть, хотя бы схематично, как в div грузится SPA приложение?

    Как-то так было.

    Серверный шаблон:
    {% extends 'base-layout.html.twig' %}
    
    {% block title %}
        Traffic controller
    {% endblock %}
    
    {% block stylesheets %}
      {{ parent() }}
      <link rel="stylesheet" href="{{ asset('css/traffic-controller/index.min.css') }}">
    {% endblock %}
    
    
    {% block content %}
      <div class="app__content" id="root">
        <span>загрузка ...</span>
      </div>
    {% endblock %}
    
    
    {% block javascripts %} 
      {{ parent() }}
      <script>
          window.__INITIAL_STATE__ = {
              // какие-то уже готовые начальные поля для данного spa 
              // полученные при серверном(!) рендеренге этого шаблона
              user: {{ user }}
          };
      </script>
      <script src="{{ asset('js/traffic-controller/index.min.js') }}"></script>
    {% endblock %}
    


    Соответствующий индексный js:
    import React from 'react';
    import ReactDOM from 'react-dom';
    import App from 'js/traffic-controller/parts/App.jsx';
    
    const rootNode = document.getElementById('root');
    ReactDOM.render(<App />, rootNode); 
    
  • Состояние дел в сфере микрофронтендов
    +1
    Пару лет назад делал приложение типа CRM-ки. Визуально была боковушка-сайдбар с кучей менюшек, и центральная контентная часть.
    Бекенд на symfony. Сверстал базовый шаблон с сайдбаром в серверном шаблонизаторе. Т.е. меню генерировалось на сервере. Каждый пункт меню — это ссылка, которая вела на отдельный серверный роут.
    При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).
    Т. е. на каждый серверный роут был отдельный twig-овский шаблон (унаследованный от базового) со своим отдельным подключёнными js- и css- бандлами, актуальными для данного пункта меню (роута).
    При достаточно функционально огромном приложении — получился довольно лёгковесный фронт, максимум 1,1мб на роут (там где графики всякие).
    Заголовок спойлера
    Можно было ещё вынести общие части (react и др.) в отдельный чанк и подключить его в базовом шаблоне. Чтобы браузер закешировал общий бандл и при переходе между пунктами меню выкачивал только нужное.


    Можно ли назвать такой подход «микрофронтендами»? хотя такого выражения тогда ещё вроде не было..))
  • Самомотивация технаря: уравнение прокрастинации, эффект шредера и трюки с едой
    0
    Когда-то давно из этого видео «узнал», что вместо того, чтобы надеяться на мотивацию лучше прокачивать свою дисциплину. Прямо очень помогло, ощущаю это буквально в любом аспекте своей жизни.
  • Про просмотр кино на английском с субтитрами, упрощение его с помощью двуязычных субтитров, и Bilingual Subtitler
    +2
    ALF на английском хорошо заходит. Субъективно речь там более членораздельная чем в Друзьях.
  • Книгообзор: Голден Кришна. «Хороший интерфейс — невидимый интерфейс»
    0
    Тезис 3. Лучший дизайн — тот, которого не видишь

    Ещё слышал такое):
    Идеальный интерфейс — это не кнопка «Сделать всё хорошо», идеальный интерфейс — это когда уже всё хорошо.
  • Цветовая схема без помощи дизайнера
    –1
    Особо не вникал в статью, но просто интересно — ваше решение чем-то отличается от онлайн-сервисов типа таких?:
    www.colorhexa.com
    palx.jxnblk.com
  • Артикли в английском: безжалостная война правил и исключений
    +1
    Здесь человек предлагает абстракцию по вычислению нужного артикля, которая по идее должна покрыть до 90% случаев в статье.
  • Простой подход к работе с отзывчивыми изображениями
    0
    Браузер выберет наилучшее изображение, руководствуясь сложным набором критериев, в которые входит то, изображение какого размера выводится у пользователя, то, каков текущий размер области просмотра, и то, имеется ли у пользователя дисплей высокого разрешения.

    Когда-то ещё упоминали, что браузер может также учитывать качество интернет соединения. Не проверяли такие случаи?
    Условно, даже если у клиента ретина дисплей, но медленный интернет — скачается картинка с меньшим разрешением, а не с 2x.
  • Пишем современный маршрутизатор на JavaScript
    0
    А как вы представляете себе тот же vk или facebook без client routing-а?

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

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

    Обычный пользователь не поймёт, он туда даже не смотрит.

    Я постоянно наблюдаю ситуацию, когда пользователь просто кликает раз пять «back» что бы вернутся на какой нибыть продукт, который был открыт ранее. Потому что так проще и быстрее, чем открыть страницу списка товаров, кликнуть в поле поиска и вбить имя товара или его номер.

    Если вы говорите про какие-то интернет магазины / блоги, где основной так сказать «business value» — это фильтры и карточка товара / статьи, которые должны в первую очередь индексироваться поисковиками, то делать это как SPA считай разводить заказчика на деньги.
    Такие вещи делать необходимо как раз-таки с классическим серверным рендерингом (не SSR который оживляет SPA, а по старинке — серверные html-шаблоны), и с серверным роутингом. При этом где какой роут (его название, глубина и т.д) должен соответствовать какой странице — решает в первую очередь seo-специалист, а не фронт на свой вкус. Да, внезапно, на бекенде придётся больше поработать чем на фронте..)
  • Пишем современный маршрутизатор на JavaScript
    0
    И url это удобный инструмент для фиксирования или указания состояния.

    Как не ищу, всё никак не могу найти плюсы клиентского роутинга. Напротив — одни проблемы. Особеннно когда делают несколько уровней вложенности, а в особых случаях даже на попапы отдельные роуты заводят. Но при этом забывают, что пользователь может нажать f5 — и всё то, что он накликал до этого теряется и приложение падает. А потом просят исправить.

    В плюсы роутинга можно отнести:
    навигация средствами браузера Back/Forward
    навигация по истории браузере

    Чувствуете «семантику»?..)
    Браузерные кнопки Back/Forward — служат для навигации по истории БРАУЗЕРА. Перебивать его клиентским роутингом — это какой-то костыль, можно сказать «несемантично».
    Если нужна навигация по истории внутри ПРИЛОЖЕНИЯ — это делается кнопками в интерфейсе самого приложения. Как правило всегда есть кнопки «назад», «отменить» и т.п. Если таких кнопок в интерфейсе нет — то значит навигация этому приложению и не нужна вовсе.
    SPA — ОДНОстраничное приложение, опять «семантика» ощущается..) Оно как бы за себя говорит — что должно находится на одном серверном роуте.

    На самом деле для себя вижу только один кейс для клиентского роутинга — когда пользовательский сценарий приложения предусматривает сценарий «поделиться ссылкой на текущую вьюху» (тот же Zeplin онлайн допутим). Т.е. это есть в требованиях. Буду рад если подскажите ещё кейсы.

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

    Более того, некоторые пользователи ожидают и хотят, чтоб при рефреше странички — всё сбросилось в первоначальный вид и можно было начать заново. Например затупил где-то, или запутался где-то глубоко в интерфейсе. Да и приложению полезно — память подчистится, всё проинициализируется в правильном порядке, менее бажный код, больше надёжность вобщем.

    Вобщем мой поинт в следующем:
    — Роутинг — это про навигацию по истории браузера.
    — Для навигации по истории приложения — лучше использовать элементы интерфейса самого приложения.
    — Добавлять клиентский роутинг — только при явных требованиях, а не раньше времени, просто потому что так принято (ещё и ~+25кб тянуть).

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