Кто-То пробовал wouter роутер? Как впечатления, есть какие-то видимые преимущества/недостатки

относительно react-router?

чиго то там в нем не было🤔 уже чет не вспомню

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

Как по мне, этому место как раз в компонентах, так что это ок в этом плане Хотя, конечно, это не очень гибко🤔

<Redirect /> - это верх идиотизма, просто декларативность головного мозга

+

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

Ну вот роутинг это чистая логика

Не согласен

Имеешь право

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

1. Я не упоминал СТМ, а только сказал про использование ВНЕ реакта 2. Не вижу ничего тяжелого положить это нагрузку на СТМ, в чем порблема?

Я говорю не о "тяжести", а о том, что это работа уровня представления, на мой взгляд

Ты можешь ограничить логику роутинга только представлением?

Не понял вопрос

Удобно ли хранить всю логику роутинга в реакте?

это от задачи и обстоятельств зависит

На мой взгляд - да Я считаю, что роутинг - это чисто деталь слоя представления

Зависит, но будет удобно только когда у тебя роуты статические ну максимум с переменными из урла. Как только начинаются таски с кондишенал редикретами от запросов, то становится больно с этой "декларативностью" И это не беря в учет ssr

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

Получу результат запроса и буду делать редиректы из нужного компонента🤷🏻‍♂️

Меня вот эта фраза интересует кодом "буду делать редиректы из нужного компонента🤷🏻‍♂️"

Заюзаю history для этого, код писать лень) Мой поинт в том, что делать я это буду в компоненте А у wouter есть хук useLocation, который возвращает метод setLocation, если я правильно понял - это то же самое, что history.push

Почему не <Redirect /> ? Тогда у тебя во вьюху прокрадется императивный код а ля if (smth) history.push()

ну да сайд эффекты не круто но с ними приходится жить

Это можно завернуть в какой-то хук, который сделает это все декларативным (как в примере из wouter) И, опять же, я говорил не об императивности, а о том, что, на мой взгляд, роутинг - ответственность слоя представления, потому предпочитаю с ним работать из компонентов

Volodymyr Klimov

Ну так вот тут бизнес логика прокралась в представление

setLocation - это бизнес-логика?

да вызов сетлокейшн это бизнес логика, ну так как зачастую там еще будет развилка куда редиректать

Я так не считаю. Это логика, конечно, но, опять же, я считаю, что она ближе к слою представления. Страницы - это то, как представляются данные, урлы могут меняться, страницы могут меняться, данные и работа с ними при этом может оставаться неизменной

Сегодня я хочу, чтобы у меня было три страницы и делаю редиректы на основе каких-то данных, а завтра объединю две страницы в одну, например, при этом изменится то, как и где я представляю данные, и все)

роутинг !== страницы Представь что тебе нужно проксировать из инпута поиска товара в квери стринг. Это как то связано с вьюхой?

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

Мы же не говорим о запросах, и я не говорил, что "за запросы из компонентов", получение данных - ответственность транспортного слоя, который тоже является деталью реализации, о которой бизнес-логика знать ничего не должна, а роутинг - ответственность слоя представления) Грубо говоря, я против, чтобы что-то кроме компонентов, которые непосредственно взаимодействуют с DOM, хранилось там, где я работаю с бизнесс-логикой

Это как если бы вам orm диктовала, куда редиректить пользователя при ошибке на беке)

Так если ты не будешь делать запросы в компонентах то как будешь делать редирект?

Опираясь на данные, которые этот компонент получает🤷🏻‍♂️ Ну, типа, надо смотреть конкретные сценарии, я просто не на столько мотивирован в результате этой дискуссии, чтобы сейчас бежать писать код)

Шо там того кода if (props.smt) history.push() Еще разик а теперь представь что props.smt это результат запроса какого либо и изменились правила и если пришел особый тип ответа то нужно редиректить в другое место, что изменишь?

А если изменился формат данных, которые отображает компонент, что будете менять?

Компонент. Но формат не менялся, появилось дополнительное условие Например если пришел пустой массив то редирект в другое место

Отлично, почему менять это где-то вне реакта лучше, чем внутри реакта?

Ровно по той же причине что и запросы вне компонентов лучше чем внутри

Не вижу связи, запросы - это способ получения данных из внешнего мира, о котором компонент не должен знать, история - это чисто браузерное апи Я не считаю компоненты реакта чисто "версткой", компонент - это и логика тоже, так вот почему логика изменения урла, на котором отображено какое-то конкретное состояние - это ответственность НЕ слоя представления (компонентов)?

Роутинг !== браузерное апи Роутинг это комбинация состояния и видимости компонентов + проекция в урл\хистори (в случае с браузерного окружения)

Я сказал, что history - это браузерное апи

Замечательно, пускай этим занимается слой представления Потому, что видимость или не видимость чего-то - это, как раз, его задача, по-моему)

Да все верно, но состояние урла\стека_хистори не отвественность вьюхи

Состояние стека истории - это ответственность браузера, мы просто пользуемся этим апи. history - это ведь уже "сервис", который внутри инкапсулирует работу с низкоуровневой штукой

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