В реакте так и принято сохранять авторизован пользователь или нет

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

Не безопасно. Доступ к приватным роутам можно получить, если захотеть. Но данные хотя бы защищены будут. Тоже ща исследую эту тему. Пока что остановился на динамичемких импортах и лейзи компонентах. Несколько отдельных js. К некоторым доступ только по http only cookie, в котором токен

Не обязательно. Можно просто в интерсепторах перехватывать все ответы от сервера, проверять 401 код, и если пользователь будет не авторизован, то редиректить его на форму логина. А в каждом компоненте делать проверку в юзЭффекте на наличие токена, если его нет, то опять же редиректить на форму логина.

можешь скинуть какую нить статью по поводу lazy загрузки приватных роутов. ну типо зачем их грузить когда пользователь не авторизован

вы про обсерверы типа rxjs ?

Не могли бы скинуть статью какую чтобы про это почитать ?

нигде не нашел. пока что только в голове. пока планирую лейзи роуты сделать https://reactjs.org/docs/code-splitting.html#route-based-code-splitting как только пользователь перейдет на них, то по идее он запросит protected js файлы. если у пользователя была кука, то он сможет загрузить их (https://stackoverflow.com/a/26450582). если у пользователя не будет куки, то в реакте какой-нибудь ErrorBoundary сработать должен

Как мне сказали сервер все равн данные не дает, смысл интерфес защищать.

у меня у лида шиза. он не хочет отдавать этот код админский

А тут у меня, вопрос такой появился.

Я не про них.

Загугли , axios interceptors , много статей с примерами есть. Да и в самой доке тоже.

Вот с ним мало работал. Спасибо. Гляну.

В любой библиотеке для работы с http , как правило есть тоже свои интерсепторы.

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

В fetch они есть ?

Нет, но это и не библиотека

бизнес логика в интерцепторах 😊😊😊

В чем тут бизнес логика? Логика по обновлению токена ?

редирект на форму логина

предлагаешь абсолютно каждый запрос в компонентах проверять?

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

Ну хорошо, редирект тогда из компонента можно делать. В промисе проверять код ответа, если он 401, то редирект куда тебе нужно. А в самом интерсепторе только логика связанная с токенами и их обновлением.

хук проще юзать кастомный. какой нить useRequest

Суть одна и та-же. Если проблема только в том, чтобы не делать редирект внутри интерсептора, то это дело легко выносится.

понял, я поэтому и не знал про перехватчики.

А вообще да, лучше конечно самописные каракули, особенно для не опытных людей😊

ну так пусть неопытные опыта набираются а не на либы полагаются

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

да забей, всегда найдётся тот кто критикует но ниче не предлагает

fetch, вопросы?

Где гарантии, что твоя рукопись будет менее уязвима и в целом лучше работать, чем реализация этого в библиотеке? Ты даш такую гарантию на 100 процентов? Или это только догадки , что у тебя будет лучше? Не думаю что из всех тут сидящих есть много тех, кто сделает лучше чем уже есть, я не говорю про тех у кого опыт 5 лет конечно. Но они как правило такими вопросами и не задаются.

ты так пишешь, будто либы тебе что-то гарантируют)

Ну как правило, разработчики библиотеки стараются по возможности следить за этим, особенно если ее часто используют. В любом случае там лучше, чем сделает какой-то джун которому сказали что лучше самому все написать.

фетч не рукопись же 🤷‍♂️

Причем тут фетч? В данной ситуации речь шла об интреспеторах, реализации которых нет в фетч, тебе придется делать это самому.

Да я как понял они и не нужны.

Да, и на чем такой вывод основан?) Или ты ручками хочешь после каждого запроса на сервер делать нужные проверки или заголовки менять?)

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

Авторизация, работа с токенами. Банально.