c
тогда получается что в публичном апи должны быть только эвенты)
вот к этому я тоже прихожу… в requirements тоже только ивенты
есть только два типа ивентов:
1 — наружу (somethingHappened)
2 — внутрь (doSomething)
Size: a a a
2020 June 03
🦜
тогда получается что в публичном апи должны быть только эвенты)
у меня сейчас в проекте так
🚀🚀
хм, я ожидал больше негатива 😅 ну хорошо, если это так)
🚀🚀
есть только два типа ивентов:
1 — наружу (somethingHappened)
2 — внутрь (doSomething)
1 — наружу (somethingHappened)
2 — внутрь (doSomething)
о, а вот эта маркировка по именам норм идея
🚀🚀
вот к этому я тоже прихожу… в requirements тоже только ивенты
но идею requirements я ещё до конца не осознал) возможно нужно больше кода с ним для изучения
🦜
к сторам давать прямой доступ, я сразу подумал, что плохая идея и первое что пришло, это общение через forward и публичные ивенты модели
c
о, а вот эта маркировка по именам норм идея
я сначала юзал только события: somethingHappened
ибо везде были уже случившиеся
но потом разродилось всяких событий, которые нужно совершить
и родились doSomething, ведь некое действие только будет совершено
и вдруг оказалось, что два типа вполне полноправные и очевидные
но вот с глаголами у которых нет второй формы проблема, типа split
ибо везде были уже случившиеся
но потом разродилось всяких событий, которые нужно совершить
и родились doSomething, ведь некое действие только будет совершено
и вдруг оказалось, что два типа вполне полноправные и очевидные
но вот с глаголами у которых нет второй формы проблема, типа split
I
ну реализуй мне кейс, который я выше описал
https://t.me/effector_ru/124675
https://t.me/effector_ru/124675
А в чем вообще проблема? Можно же сделать форвард из $user.updates.map(user => user !== null)
R
const $user = createStore<User | null>(null)
export const $isAuth = $user.map(user => user !== null)const $user = createStore<User | null>(null)
const $isAuth = createStore<boolean>(false)
sample({
source: $user,
fn: user => user !== null,
target: $isAuth,
})
const $isAuth = createStore<boolean>(false)
sample({
source: $user,
fn: user => user !== null,
target: $isAuth,
})
I
ну или сэмпл, да, без разницы то
c
const $user = createStore<User | null>(null)
const $isAuth = createStore<boolean>(false)
sample({
source: $user,
fn: user => user !== null,
target: $isAuth,
})
const $isAuth = createStore<boolean>(false)
sample({
source: $user,
fn: user => user !== null,
target: $isAuth,
})
проблема начинается когда начальное значение стора $user изменяется
c
кто гарантирует корректное вычисление?
c
а если там гораздо сложнее вычисления?
R
проблема начинается когда начальное значение стора $user изменяется
руками?
c
руками?
ой прости
c
мы ж вроде все руками писать собираемся
c
нам же не надо ничего упрощать
R
руками поменяешь и isAuth
c
потрясно