Комментарии 13
Поэтому, для одностраничного приложения смена компонентов и изменения внутреннего состояния приложения всегда должно сопровождаться изменением url.
Всегда? Если нет требований, то зачем? Тащить ещё 20кб кода в проект?
Без требований, по какому принципу решать, какой компонент должен соответствовать какому роуту? И как эти роуты называть? По какому принципу решать, какая глубина роутинга нужна?
Из любого правила существуют исключения. Наверное есть проекты в которых можно обойтись без игр с url.
Но чаще всего это нужно. Если речь идёт о общедоступном приложении напрмер витрине веб-магазина, наверное где-то будет размещаться реклама со ссылкой на товар. Если это закрытая админка, также может понадобиться перейти по ссылке например на конкретный раздел например из почтового сообщения.
Но даже если этого ничего не требуется. Мы не можем запретить пользователю перегружать страницу или использовать навигацию по истории. Если при перегрузке будет отображаться всегда исходная точка входа в приложение это может восприниматься как баг.
Мы не можем запретить пользователю перегружать страницу или использовать навигацию по истории. Если при перегрузке будет отображаться всегда исходная точка входа в приложение это может восприниматься как баг.
Но мы также не можем запрещать пользователю навигацию по истории браузера (перебивать клиентским роутингом).
Обновление, оно же refresh / reload, предполагает обновление страницы. Поэтому если нет требований по сохранению состояния при перезагрузке, то смысл его делать раньше времени нет.
Обычно если пользовательский сценарий в приложении включает историю и возможность откатиться назад на какое-то состояние, то эта возможность обычно есть и в самом ui приложения (кнопка «вернуться назад», и т.д.)
Если речь идёт о общедоступном приложении напрмер витрине веб-магазина, наверное где-то будет размещаться реклама со ссылкой на товар.
Если это что-то общедоступное, которое должно индексироваться, тем более если веб-магазин — то тут уже больше нужны классические серверный рендеринг и серверный роутинг, а не spa) И там требования к роутам составляют seo-специалисты.
Но чаще всего это нужно.
Вобщем-то я только в этом не согласен был в первом своём сообщении.) Считаю, что чаще клиентсикй роутинг не нужен, чем нужен. Не люблю когда его тащят по принципу чтоб было.
Как появятся конкретные требования — так тогда и прикрутим. мир..)
Сталкивался не раз с тем что заказчик просто нажимает когда хочет F5 и говорит у Вас баг и крыть нечем. Мы же не отключили кнопку F5. А внедрить роутинг в готовое приложение практически бесперспективное занятие если он изначально не был предусмотрен.
Ну если говорить строго то описываемая либа universal-router это 6Кбайт
https://raw.githubusercontent.com/kriasoft/universal-router/master/dist/universal-router.min.js
router5 — да там 27
bundlephobia.com/result?p=react-router-dom@5.1.2
Сталкивался не раз с тем что заказчик просто нажимает когда хочет F5 и говорит у Вас баг и крыть нечем.
Крыть можно тем, что это не баг, а запрос на новый функционал) Как раз можно сесть, и проговорить, какие именно состояния в приложении он хочет чтобы сохранялись при рефреше странички.
Другой же напротив, хочет чтоб при рефреше — полностью всё обновилось и сбросилось к первоначальному виду. Мало ли, запутался в интрефейсе, или что-то не работает, хочет начать всё по новой. Это вроде как более ожидаемое поведение при F5, если ранее не оговоривалось иное.
На самом деле, если при рефреше какой-то стейт должен сохраниться, то с большой долей вероятности, это также сохраняется и на сервере. Например, какой-то шаг в какой-то анкете/визарде. И тогда при обновлении странички фронт уже знает что нужно отрисовать без всякого роутинга.
А внедрить роутинг в готовое приложение практически бесперспективное занятие если он изначально не был предусмотрен.
По мне наоборот. Внедрить роутинг по внезапным требованиям в чистое приложение проще, чем в то, где роутинг сделан сначала на усмотрение разработчика.
onClick={createOnClickAnchor(onClick)}
А вы не тестировали на предмет лишних перерендериваний? Я вижу performance issue из-за каждый раз создающейся функции-обработчика, в этом месте
Да конечно нужно будет переделать. Я вообще-то использовал этот роутер с riot https://github.com/apapacy/realworld-riotjs-effector-universal-hot/blob/master/src/riot/navigationLink.riot а код для react скопипастил из статьи на которую привел ссылку. Т.к. riot вряд-ли кому-то был бы интересен.
Спасибо за замечание.
Скорее всего issue было вызвано фрагментом кода с умолчательной пустой функцией onClick = () => {} я заменил в коде на onClick = noOp
Универсальный роутинг для React приложений