🦜
сделай эвент типа flush или endTransaction или forceUpdate
и в sample по нему собирай в кучу данные из разных сторов, а компонент подпиши на результат
Size: a a a
2020 July 20
A
да, я уже тоже думал про такое, но предложили вариант менее мозговыносящий)
спасибо за помощь, энивейс)
спасибо за помощь, энивейс)
🅅🄺
да, я уже тоже думал про такое, но предложили вариант менее мозговыносящий)
спасибо за помощь, энивейс)
спасибо за помощь, энивейс)
куда уж менее то?
это самый правильный вроде и управляемый
это самый правильный вроде и управляемый
A
сделай эвент типа flush или endTransaction или forceUpdate
и в sample по нему собирай в кучу данные из разных сторов, а компонент подпиши на результат
и в sample по нему собирай в кучу данные из разных сторов, а компонент подпиши на результат
потому что там дерево
придется тогда собирать апдейты снизу вверх, от чайлда к паренту, а потом применять на самом верхнем уровне
придется тогда собирать апдейты снизу вверх, от чайлда к паренту, а потом применять на самом верхнем уровне
🅅🄺
потому что там дерево
придется тогда собирать апдейты снизу вверх, от чайлда к паренту, а потом применять на самом верхнем уровне
придется тогда собирать апдейты снизу вверх, от чайлда к паренту, а потом применять на самом верхнем уровне
очень странно звучит
🅅🄺
либо нет смысла так дробить данные на сторы
🅅🄺
либо нужно концепцию пересмотреть
A
мб
без контекста сложно наверное здраво судить, о целесообразности, но я раскрывать пока не буду 🌚
хотя тут уже намекнули
без контекста сложно наверное здраво судить, о целесообразности, но я раскрывать пока не буду 🌚
хотя тут уже намекнули
🅅🄺
мб
без контекста сложно наверное здраво судить, о целесообразности, но я раскрывать пока не буду 🌚
хотя тут уже намекнули
без контекста сложно наверное здраво судить, о целесообразности, но я раскрывать пока не буду 🌚
хотя тут уже намекнули
если речь о формах, то делать изменения в родителе зачем?
🅅🄺
ты же не хочешь перерисовывать всю форму
🅅🄺
ну или все дерево
A
если речь о формах, то делать изменения в родителе зачем?
есть следующая схема данных:
{
foo: {
bar: {
baz: number, <— я меняюсь
},
quix: string
}
}
какое поведение мы ожидаем?)
без привязки к реактам, и рендерилкам вообще
DS
если речь о формах, то делать изменения в родителе зачем?
А вы вот те страшный генератор форм на конфигах на эффекторе писали?
A
мне кажется, что должен стрельнуть онченж у формы, на самом верхнем уровне
с ошибками и валидацией, таже песня
с ошибками и валидацией, таже песня
A
в рендере будет просто подписка на кусок формы, это уже другой вопрос)
🦜
есть следующая схема данных:
{
foo: {
bar: {
baz: number, <— я меняюсь
},
quix: string
}
}
какое поведение мы ожидаем?)
без привязки к реактам, и рендерилкам вообще
ну если ты хочешь точечные апдейты, то на каждое поле свой стор
A
ну если ты хочешь точечные апдейты, то на каждое поле свой стор
ну в целом, там так и есть
ща реализовано так, что все примитивные типы данных изменяются в общей куче, все вложенные куски формы - отдельные сторы
получится стор с 3мя полями, в котором foo, bar - просто лежат в общей куче, и меняются как есть, а baz через подписку на изменение чайлд куска формы
ща реализовано так, что все примитивные типы данных изменяются в общей куче, все вложенные куски формы - отдельные сторы
{
foo: string,
bar: number
baz: {
quix: boolean
}
}получится стор с 3мя полями, в котором foo, bar - просто лежат в общей куче, и меняются как есть, а baz через подписку на изменение чайлд куска формы
🦜
const field = createStore('', {name: 'foo.bar.baz'})
const form = combined(field, (f) => {[f.name]} : f )
const form = combined(field, (f) => {[f.name]} : f )
🦜
может как-то так со вложенностями
A