😂😁👍

Ок спасибо буду фигачить

И альтернативы
https://stackshare.io/sentry/alternatives

спасибо.
раньше слышал об этом, но не мог найти именно то, что нужно .
спасибо, очень помогли

Как можно сделать один общий метод для всех компонентов?

В каких-то компонентах у меня фетчаться данные по апи, и если токен истек, а значит юзер не авторизован, то мне его надо редиректить на страницу авторизации.

axios интерцептор

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

для таких ситуацию юзают

как там редирект сделать?

издеваешься?

вью роутером

отчистив токен

Сейчас не понял

Сейчас понял

Это не нарушает Flux pattern?

В Nuxt для этого используются безымянные middleware

Проверка валидности токена проверяется в более раннем middleware , который отрабатывает еще до создания компонента

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

Flux pattern будет нарушен только если этот токен будет изменяться/удаляться гдето вне функций мутаций хранилища

Просто сейчас структура компонентов такая:
Компонент UserDataProvider, path: '/'
В нем идет проверка, если токен есть в локал сторадж и юзера нету в  store, то мы его фетчим.
И все роуты приложения находятся в children у UserDataProvider.

UserDataProvider:
path: '/',
children: [ all routes ]

И мне подсказали делать проверку в этом компоненте, если сервер возвращает ошибку 401, то редиректим на логин страницу, но так будет работать только если юзер перезагрузит страницу, если он ее не перезагрузит, то все данные остануться, но оперировать он ими не сможет

UserDataProvider:
path: '/',
children: [ all routes ]

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

и проверка наличия токена на  уровне логики авторизации должна происходить обращением к Store, а не к LS тк логика авторизации должна быть абстрагирована от логики сохранения данных. Поток данных должен быть однонаправлен и ортогонален. Если токен получается в Store, то он всегда должен только оттуда и получаться

Проверка LS на наличие токена должна быть тоже middleware и должна устанавливать этот токен в Store
Это базовые принципы разделения обязанностей