🚀🚀
в нём выбрасывается ошибка если вызов эффекта не требуется
Size: a a a
2021 June 18
IK
Уууууу
🚀🚀
но техническое обоснование этого довльно неожиданное
🚀🚀
прям реально неожиданное, мы встали перед этим фактом уже после релиза)
🚀🚀
когда мы говорим об обычных вычислениях, то ошибки в чистых функциях означают, что дальше процесс вычисления не пойдёт, то есть всё прозрачно — ну нет вычисления и нет
изначально предполагалось, что mapParams — такой же
const e = createEvent()
const $a = createStore(0)
const $b = $a.map(x => x + 1)
$a.on(e, (x, fail) => {
if (fail) throw Error()
return x + 1
})
e()
// => $a = 1; $b = 2
e(true)
// => нет реакции, но всё консистентноизначально предполагалось, что mapParams — такой же
K
а как книжка называется если не секрет?)
EГ
Дизайн привычных вещей
АБ
дизайн привычных вещей
ei
дизайн привычных вещей
EГ
почему просто не result например, интуитивно должно быть понятно?
АХ
Бред или нет:
Кажется, если сделать
- то можно будет оставить guard как алиас и со временем депрекейтнуть его
Т.е. +1 поле у сэмпла и да, нужно будет помнить, что fn вызывается отдельно после фильтра
Но -1 целый оператор, с которым нужно отдельно разбираться и проводить параллели с сэмплом
И в итоге апи в целом стало меньше и его проще в голову загрузить
Или это не так работает? 🤔
Кажется, если сделать
sample({
source,
clock,
filter,
fn,
target
})- то можно будет оставить guard как алиас и со временем депрекейтнуть его
Т.е. +1 поле у сэмпла и да, нужно будет помнить, что fn вызывается отдельно после фильтра
Но -1 целый оператор, с которым нужно отдельно разбираться и проводить параллели с сэмплом
И в итоге апи в целом стало меньше и его проще в голову загрузить
Или это не так работает? 🤔
🚀🚀
на практике же выяснилось, что отличается как ожидаемое людьми поведение, так и реакция системы в целом:
как итог, второй промис зависает в бесконечности, потому что mapParams не выполнился до конца. из этого следует, что ошибки из mapParams обязаны попадать в fail аттачнутого эффекта. а это означает, что mapParams — функция с сайд-эффектами
целая теорема получилась)
const fx = createEffect(() => 1)
const att = attach({
effect: fx,
mapParams(fail) {
if (fail) throw Error()
}
})
const req1 = att()
// Promise {fullfilled: 1}
const req2 = att(true)
// Promise {pending}
как итог, второй промис зависает в бесконечности, потому что mapParams не выполнился до конца. из этого следует, что ошибки из mapParams обязаны попадать в fail аттачнутого эффекта. а это означает, что mapParams — функция с сайд-эффектами
целая теорема получилась)
EГ
ты забыл типы и тест кейсы и тесты типов, я теперь понимаю через что Дима проходит, когда думает о добавлении фичи
хватает нюансов
хватает нюансов
DS
Проблема не в "нужно помнить" а в потенциально необходимых кейсах. Не хотелось бы добавить сложности апи и потом понять что остались непокрытые эджкейсы. Это будет привнесеной сложностью
🚀🚀
в плане типов для начала достаточно просто поверхностного обзора ситуаций, чтобы убедиться, что идея в принципе типизируется
DS
Условно расширить семпл и потом обнаружить что в каких то кейсах все равно прийдется использовать композицию семпл + гард
🚀🚀
в целом можно резюмировать, что pre-filter реально не нужен, но это не избавляет от необходимости выбирать понятное имя для post-filter
🚀🚀
я в принципе понимаю о чём он)