AO
@ZeroBias а к тебя нет под рукой примера когда использование .getState даёт не то значение которое ожидается ?
Size: a a a
2020 August 14
AO
Просто вопросы про .getState возникают постоянно, и вот на неделе тоже был и я сам в результате попытки объяснить запутался и понял что не понимаю
🚀🚀
ну вообще тут такой момент — имплементация эффектора по максимуму делает так, чтобы эти гонки были не видны, но они вызываются самой природой вычислений в сложной системе — помните, что в redux getState внутри редьюсера приводит к исключению? это сделано для того, чтобы ты не смог прочитать что-то, в то время как твой код это самое что-то обновляет
🚀🚀
поэтому в простых кейсах getState всегда выдаёт ожидаемое значение, просто потому что эффектор над этим работает со своей стороны, а мы со своей — не абьюзим этот механизм, делая его исключительным случаем, а не повсеместной практикой
🚀🚀
проще говоря, чтобы увидеть проблемы с getState нужно написать достаточно кода с его использованием: https://t.me/effector_ru/123789
DS
Нам нада треша и поломки🌚
🚀🚀
например, если от одного и того же эвента триггерить обновление двух сторов, то начинает играть роль порядок
🚀🚀
Aleksandr Osipov
@ZeroBias а к тебя нет под рукой примера когда использование .getState даёт не то значение которое ожидается ?
AO
Спасибо! Тред сохранил
🚀🚀
и из этой ситуации есть два выхода — либо следить за порядком, либо использовать инструменты для избавления от необходимости в соблюдении порядка
AO
В общем очень круто выходит что эффектор сопротивляется до последнего поломкам:) И .getState в основном кроме edge cases выдает ожидаемое значение и внутри .on можно события дергать и так далее
🚀🚀
ага
🚀🚀
например учитывается как кейс в котором чистая функция превращается в ватчер https://t.me/effector_ru/154098
🚀🚀
так и ещё более эзотерические ситуации, которые, при этом, были взяты из реальной практики (это тест на то, что history успеет обновиться)
https://github.com/zerobias/effector/blob/master/src/effector/__tests__/kernelEdgeCases.test.ts#L44
https://github.com/zerobias/effector/blob/master/src/effector/__tests__/kernelEdgeCases.test.ts#L44
NF
это решается создав стор зависимый от стора явно?
🚀🚀
так и ещё более эзотерические ситуации, которые, при этом, были взяты из реальной практики (это тест на то, что history успеет обновиться)
https://github.com/zerobias/effector/blob/master/src/effector/__tests__/kernelEdgeCases.test.ts#L44
https://github.com/zerobias/effector/blob/master/src/effector/__tests__/kernelEdgeCases.test.ts#L44
то есть, даже если ты воспользуешься getState в on, эффектор постарается сделать так, чтобы результат соответствовал ожиданиям. и это всё работает только при условии, что в среднем по приложению необходимость использования getState отсутствует, то есть это не чёрное и белое, это плавное уменьшение предсказуемости
NF
это решается создав стор зависимый от стора явно?
типа как в этом примере
const balance = createStore(0)
const username = createStore('zerobias')
const greeting = combine(balance, username, (balance, username) => {
return `Hello, ${username}. Your balance is ${balance}`
})
🚀🚀
это решается создав стор зависимый от стора явно?
тут несколько сложнее — заметь, что стору a необходимо значение из b только при срабатывании trigger, поэтому это кейс для sample
🚀🚀
но и sample/guard и combine всегда ждут, пока используемые ими состояния стабилизируются, и лишь затем начинают работу
DS
https://share.effector.dev/hejQxkDO
Блин наконецто для меня хоть чуть прояснилось
Блин наконецто для меня хоть чуть прояснилось
