🚀🚀
ну да
Size: a a a
2021 March 24
V
Окей гуд
c
Спасибо, а есть ли способ сделать reset сразу на все сторы в каком то конкретном домене или надо каждый стор отдельно обработать?
onCreateStore как раз и позволяет
здесь callback будет вызван для каждого стора в домене
собственно и повесим на каждый стор сброс по событию myEvent
domain.onCreateStore(store => {
store.reset(myEvent)
})здесь callback будет вызван для каждого стора в домене
собственно и повесим на каждый стор сброс по событию myEvent
🚀🚀
Спасибо, а есть ли способ сделать reset сразу на все сторы в каком то конкретном домене или надо каждый стор отдельно обработать?
const resetStates = createEvent()
const states = createDomain()
states.onCreateStore(store => {
store.reset(resetStates)
})
const username = states.createStore('alice')
const age = states.createStore(21)
V
Просто ещё помогает в нашем кейсе помодульно логгировать
V
Вешать лишь на домен фичи аттач логгера
🚀🚀
Vetro
Вешать лишь на домен фичи аттач логгера
а, да, это фича))
🚀🚀
поэтому то юниты и наследуют имена домена
V
Отлично!
AO
S
const resetStates = createEvent()
const states = createDomain()
states.onCreateStore(store => {
store.reset(resetStates)
})
const username = states.createStore('alice')
const age = states.createStore(21)
еще раз спасибо, теперь все дошло)), он накинет обработчики на каждый стор, и они будут ресетиться
SE
Спасибо, а есть ли способ сделать reset сразу на все сторы в каком то конкретном домене или надо каждый стор отдельно обработать?
Создаем домен.
У доменна юзаем
Все сторы, которые будут созданы через этот домент (myDoman.createStore) будут обработаны через myDoman
У доменна юзаем
onCreateStoreВсе сторы, которые будут созданы через этот домент (myDoman.createStore) будут обработаны через myDoman
.onCreateStoreS
Создаем домен.
У доменна юзаем
Все сторы, которые будут созданы через этот домент (myDoman.createStore) будут обработаны через myDoman
У доменна юзаем
onCreateStoreВсе сторы, которые будут созданы через этот домент (myDoman.createStore) будут обработаны через myDoman
.onCreateStoreвсе заработало))
SE
все заработало))
.👍
TG
я услашл про либу.
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
🚀🚀
у меня такая проблема, что если 2 эффекта стартанули одновременно.
то один из них попытается сделать refresh c устаревшим refreshToken, потому что первый уже сделал refresh...
то один из них попытается сделать refresh c устаревшим refreshToken, потому что первый уже сделал refresh...
больше всего смущает вот эта проблема. может стоит позволить одному из эффектов сделать устаревший рефреш? от после этого упадёт, сделает ретрай и нормально завершится
🚀🚀
или же наоборот, координировать рефреш централизовано, через какой-нибудь флаг, чтобы если один запрос начал делать рефреш, то второй бы увидел флаг от первого и рефреш бы не делал
c
я услашл про либу.
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
я не так давно писал подобное решение для своего проекта.
и столкнулся с тем, что далеко не все запросы можно ретраить.
нельзя определить по методу GET/POST/PATCH можно ли запрос ретраить
и столкнулся с тем, что далеко не все запросы можно ретраить.
нельзя определить по методу GET/POST/PATCH можно ли запрос ретраить
c
тут стоит исходить исключительно из требований, которые уже выставлены.
c
я услашл про либу.
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
первое - она многовато весит
второе - неявный, скрытый код который я не понимаю
третье - она может не покрыть требования бэка, а доказывать что-то бэку вне моих компетенций.
четвертое - не факт что она легко закостомизируется под мой проект и эффектор
и если не хочется юзать готовую либу, придется буквально писать свою.
но чтобы сделать что-то подобное, стоит составить список требований для начала и уже потом думать, а что собственно реализовывать.
если будет готовый список, то можно будет прям здесь подумать как лучше их реализовать, да так, чтобы изменения не ломали весь код приложения
но чтобы сделать что-то подобное, стоит составить список требований для начала и уже потом думать, а что собственно реализовывать.
если будет готовый список, то можно будет прям здесь подумать как лучше их реализовать, да так, чтобы изменения не ломали весь код приложения