🚀🚀
makoven
Или у вас одно изменение стора размазано по нскольким асинхронным функциям?
всё происходящее в эффекторе строго синхронно, но ряд обновлений батчится, а батчинг подразумевает изменение порядка выполнения
Size: a a a
2020 June 26
🚀🚀
батчинг это один из самых важных моментов, к примеру combine из трёх сторов при обновлении сразу всех должен обновиться всего один раз потому что неконсистентные промежуточные состояния никого не интересуют (см. проблему лишних ререндеров в реакте)
m
батчинг это один из самых важных моментов, к примеру combine из трёх сторов при обновлении сразу всех должен обновиться всего один раз потому что неконсистентные промежуточные состояния никого не интересуют (см. проблему лишних ререндеров в реакте)
Круто. Типа транзакции для иммутабельных структур
m
батчинг это один из самых важных моментов, к примеру combine из трёх сторов при обновлении сразу всех должен обновиться всего один раз потому что неконсистентные промежуточные состояния никого не интересуют (см. проблему лишних ререндеров в реакте)
Так это всё из-за комбинаций сторов и сопутствующих им оптимизаций
🚀🚀
батчинг это один из самых важных моментов, к примеру combine из трёх сторов при обновлении сразу всех должен обновиться всего один раз потому что неконсистентные промежуточные состояния никого не интересуют (см. проблему лишних ререндеров в реакте)
🚀🚀
makoven
Так это всё из-за комбинаций сторов и сопутствующих им оптимизаций
нет, это просто лишь самый характерный пример
🚀🚀
мы не всегда вообще имеем возможность воспринимать систему точно в том порядке, в котором она будет выполняться, это не зависит ни от наличия батчинга ни от факта использования эффектора вообще: это фундаментальная проблема
🚀🚀
как я упомянул в сообщении со скрина выше, даже в чистом реакте будут расхождения между ожиданиями и реальностью, если мы начнём полагаться на то, что какой угодно дефолтный порядок выполнения будет нам подходить всегда
🚀🚀
всегда найдётся способ найти такую точку в коде, в которой императивное чтение значения будет возвращать некорректное значение: например если значение ещё не успело обновиться (забыл что функция-апдейтор вызывается позже)
🚀🚀
поэтому зависимости необходимые для выполнения кода лучше обозначить явно, тогда библиотека имеет шанс подготовить процесс выполнения правильно
🚀🚀
то есть тут обратный порядок мысли: мы даём возможность подготовиться к работе, заранее обозначая наши требования и благодаря этому появляется возможность оптимизации кода
AO
то есть тут обратный порядок мысли: мы даём возможность подготовиться к работе, заранее обозначая наши требования и благодаря этому появляется возможность оптимизации кода
Кстати, в доке есть фраза Whenever you will allow side effects in pure computations, the library will work by worst scenario - можешь разъяснить смысл?
AO
Aleksandr Osipov
Кстати, в доке есть фраза Whenever you will allow side effects in pure computations, the library will work by worst scenario - можешь разъяснить смысл?
И как это реализовано, обнаружение сайд эффектов в смысле
🚀🚀
Aleksandr Osipov
Кстати, в доке есть фраза Whenever you will allow side effects in pure computations, the library will work by worst scenario - можешь разъяснить смысл?
при императивном вызове тебя выкидывает в самый конец очереди на выполнение, фактически делая функцию любой чистоты — ватчером
AO
при императивном вызове тебя выкидывает в самый конец очереди на выполнение, фактически делая функцию любой чистоты — ватчером
Все равно не очень понятно, можно пример простой?
🚀🚀
механизм довольно простой, но тут надо начать издалека:
при императивных вызовах эвентов мы ожидаем что после их вызова все их сайд-эффекты уже отработают
при императивных вызовах эвентов мы ожидаем что после их вызова все их сайд-эффекты уже отработают
let sideEffect = 0
const run = createEvent()
run.watch(() => {
sideEffect += 1
})
run()
console.log(sideEffect)
// => 1🚀🚀
соответственно если вызвать эвент внутри другого ватчера, то поведение измениться не должно, не так ли?
let sideEffect = 0
const run = createEvent()
run.watch(() => {
sideEffect += 1
})
const wrap = createEvent()
wrap.watch(() => {
run()
console.log(sideEffect)
// => 1
})
wrap()🚀🚀
а если переместить этот код внутрь .on, то изменений по прежнему же быть не должно?
let sideEffect = 0
const run = createEvent()
run.watch(() => {
sideEffect += 1
})
const wrap = createEvent()
const x = createStore(0)
.on(wrap, () => {
run()
console.log(sideEffect)
// => 1
})
wrap()🚀🚀
но как тогда это выглядит с точки зрения очереди на выполнение: мы начинаем выполнять чистую функцию (в очереди ещё висят ватчеры), а после её выполнения оказывается, что ватчеры уже выполнены, что это, если не перемещение в самый конец?
🚀🚀
это эффект наблюдателя) своими действиями он выдаёт себя