SP
модель экспоузит ивенты/экшены/эффекты. В случае эффектора еще есть gates для некоторых кейсов или можно кастомные хуки оформить. компоненты их дергают.
Size: a a a
2021 November 23
SP
жизненный цикл UI у тебя драйвит все, есть еще аспекты которые не привязаны к жизненному циклу UI - но это при старте приложения дергается (можно вообще в вэб воркер вынести)
E
фичи между собой глобальным басом?
E
т.е. это такие вертикальные слои получаются побитые на фичи, бизнес в грубо говоря "модели", в котором как-то реализован стор и экспоз ивентов/экшенов/эффектов
SP
в случае эффектора можно делать клей снаружи. Например у тебя есть фича которая кидает ивент
videoCallStarted. и есть другая фича с таким же ивенотм который надо дернуть. Снаружи мы можем в каком init.ts прописать
forward(videoCallStarted.map({videoCallId}) => videoCallid, onVideoCallStarted)
SP
"фичи" это и есть это "вертикальное разделение".
SP
но у тебя всеравно есть некий "хост" в которм все это варится, инфраструктура которая все склеивает
SP
inversion of control
SP
don't call us, we call you вся херня
E
а мы в модель что нибудь прокидываем di ное?
E
как модель колит апишки
E
мы ей запихнем апи сервис? откуда?
E
или репозиторий?
SP
опять же как хочешь.
в эффекторе например у тебя модель может определять эффект
и где-то выше на уровне инфраструктуры ты можешь связать реализацию
в эффекторе например у тебя модель может определять эффект
const loadSomeData = myFeatureDomain.createEffect({
handler: (id: string) => Promise.reject(new Error("Not Implemented"))
})
и где-то выше на уровне инфраструктуры ты можешь связать реализацию
loadSomeData.setHandler(realLoadSomeData)
SP
вдруг ты вообще graphql юзаешь
E
ты сабмитишь в эффектор да?)
SP
неа, просто мне он оч нравится