Разнообразные. Всегда есть плюсы и минусы в том или ином решении. Например, разделив на разные back мы реализуем крупномасштабную модульность. Возможности распределения нагрузки...

Логинюсь через логин+пароль и сервер мне отдает токен который я записываю в асинкстордж. Кроме этого прописываю еще так(запросы идут через аксиос)

instance.defaults.headers.Authorization = `Bearer ${token}`;

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

login: async (data: LoginInterface) => {
    delete instance.defaults.headers.Authorization;
    return instance
      .post('/login', data)
      .then((response) => response) 
      .catch((e) => e);

Я правильно прописываю delete чтоб оно в случае если есть токен в хеадере есть его удаляло и в запросе он не шел?

instance.defaults.headers.Authorization = `Bearer ${token}`;

login: async (data: LoginInterface) => {
    delete instance.defaults.headers.Authorization;
    return instance
      .post('/login', data)
      .then((response) => response) 
      .catch((e) => e);

не совсем понятно где происходит удаление

не проще проверять на 401 статус? и в случае если он, редиректить на страницу логина и удалять

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

ок, но разве у тебя авторизация не сохраняется в приложении?

т.е чтобы сразу попасть в приложение, а не на экран логина

Он проверяет и перекидывает. Но в хеадерах еще остается  токен который был перед этим. То мне надо еще и с хеадера почистить его.

delete instance.defaults.headers.common.Authorization;

я вот так удаляю

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

и вот запись

 instance.defaults.headers.common.Authorization = 'Token ' + token;

всем доброго времени суток

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

Вот и у меня оно есть.. только  вижу что common не дописал.

А не легче/лучше написать полноценный апи сервис, где реализовать методы setToken(), clearToken() и вызывать по необходимости?

+

Это так и делается по необходимости. Но токен после очищения надо еще убрать и из хеадера т.к. для рефреша апи не предоставили. А все последующие запросы имеют в в хеадере старый токен после перенаправление на страницу авторизации.

у тебя что, несколько инстансов апи чтоли в приложении?

вот, прекрасно работает

void не дописал)