которого не было

у тебя там хуки

да это толкьо что добавил костыль для тестов...

опиши задачу полностью
не привязываясь к деталям реализации

у меня axios жил своей жизнью, эффектор своей
и вьюшка совей

ничего нигде не перескалось

обычно это так:
вьюха знает про события и сторы эффектора
эффектор через эффекты знает про аксиос

есть такая обертка над axios которая делает запрос на обновление access и refhresh токена, реализует JWT.

если вдруг запрос не удался и было получено 401, нужно попытаться основываясь на refresh токене обновить access токен.

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

блин

У аксиоса есть интерсепторы

к слову, в случае с jwt access-refresh схемой, лучше не на 401 смотреть, а не доводить до этого, и если expire меньше чем в токене с допуском некоторым то рефрешить перед запросом

ну собственно они и используются

опишу как делаю я
я выкидываю любые подобные обертки в мусорку

И начинаю с базового эффекта requestFx, который умеет лишь одну вещь: делать запросы от одного аргумента { path, method, body, headers, ... }

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

и вот затем, я создаю отдельные эффекты для каждого запроса апи, и внутри каждого использую подходящий requestFx или requestRefreshFx

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

проектируйте без костылей аксиоса и станет сильно проще
самое простое апи на функциях(эффектах) гибче всего и проще всего работает

не надо выдумывать костыли с интерсепторами, пожалуйста

+

так гораздо удобнее

у тебя проблемы в том, что некий класс Fetcher делает слишком много всего
и тупо сыпется от нарушения единственной ответственности

а вендор лочиться на либах это бред в принципе

по крайней мере в этом кейсе