🦜
у кого нибудь есть client JWT на эффектах?
на эффектах нет, брал из примеров для axios
Size: a a a
2021 March 24
c
или же наоборот, координировать рефреш централизовано, через какой-нибудь флаг, чтобы если один запрос начал делать рефреш, то второй бы увидел флаг от первого и рефреш бы не делал
да, так однозначно лучше, покрывает больше кейсов.
я реализовал такую штуку через массив флагов, каждый эффект ждет резолва своего типа флага и только тогда продолжает.
я реализовал такую штуку через массив флагов, каждый эффект ждет резолва своего типа флага и только тогда продолжает.
🚀🚀
Aleksandr Osipov
https://share.effector.dev/wnrSwRFn идею понял думаю
тут нюанс в том, что токен не может лежать просто в корне, потому что при ssr это не сработает
🚀🚀
тут нюанс в том, что токен не может лежать просто в корне, потому что при ssr это не сработает
а ssr в условии есть, это я просто сам знаю)
TG
а ssr в условии есть, это я просто сам знаю)
😄
на самом деле можно и без SSR обойтись, авторизация может не работать в условиях сервера потому что SSR только для публичных страниц.
на самом деле можно и без SSR обойтись, авторизация может не работать в условиях сервера потому что SSR только для публичных страниц.
MK
Делаете ли вы обработку ошибок эффектов домена через хук домена? Я как вижу это отличное решение для обработки стандартной ошибки при которой покажется какой-то алерт с ошибкой и отправки ошибки в сентри.
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
SE
Делаете ли вы обработку ошибок эффектов домена через хук домена? Я как вижу это отличное решение для обработки стандартной ошибки при которой покажется какой-то алерт с ошибкой и отправки ошибки в сентри.
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
Не делаю.
Все подписываю на месте
Все подписываю на месте
🚀🚀
Делаете ли вы обработку ошибок эффектов домена через хук домена? Я как вижу это отличное решение для обработки стандартной ошибки при которой покажется какой-то алерт с ошибкой и отправки ошибки в сентри.
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
А вот если на каком то эффекте нам не нужно обрабатывать дефолтную ошибку, а выполнить что то другое?
https://share.effector.dev/q2O8lh4m
forward({
from: [fetchUserFx.fail, fetchMessageFx.fail],
to: sendToSentryFx
})MK
forward({
from: [fetchUserFx.fail, fetchMessageFx.fail],
to: sendToSentryFx
})Да но не это не избавит от дефолтной обработки
FB
forward({
from: [fetchUserFx.fail, fetchMessageFx.fail],
to: sendToSentryFx
})Или опять же, хук домена..
MK
вобщем как я понял лучше каждую отдельно
🚀🚀
Да но не это не избавит от дефолтной обработки
я про то, что это вместо дефолта
🚀🚀
домены намеренно сделаны деревьями а не графами, чтобы не усложнять понимание (это мы сейчас помним что этот эффект — исключение, а через пол года?)
🚀🚀
поэтому если кейс выходит за кейсы домена — переключаемся на явное описание
MK
я про то, что это вместо дефолта
щас сделаю другой пример
TG
сделал репродюс моей проблемы с реализацией авторизации на access + refresh токенах:
https://share.effector.dev/6oc5fHYG
https://share.effector.dev/6oc5fHYG
TG
до 36-й строки имитация сервера который выдает и проверяет токены.
TG
а сама проблема после 36-й строки.
в самом конце 2 примера один из которых делает репродюс проблемы.
в самом конце 2 примера один из которых делает репродюс проблемы.
🚀🚀
а сама проблема после 36-й строки.
в самом конце 2 примера один из которых делает репродюс проблемы.
в самом конце 2 примера один из которых делает репродюс проблемы.
оо, репродьюс это прям отлично) так намного понятнее