OR
а зачем? лучше же делать e.preventDefault() императивно, потому что чаще всего нужен if (x) { e.preventDefault() }
чаще всего?
Size: a a a
2020 September 18
🚀🚀
а зачем? лучше же делать e.preventDefault() императивно, потому что чаще всего нужен if (x) { e.preventDefault() }
> зачем
для того чтобы не равнять оставшихся под мнимые общие кейсы
для того чтобы не равнять оставшихся под мнимые общие кейсы
🚀🚀
если тебе надо то у тебя по прежнему есть if
NF
чаще всего?
ну когда я писал хэндлеры у меня всегда была какая-то условная логика, я тогда ещё бугуртил с того что в ko изменены умолчания для обработчиков
🚀🚀
это как аргументация почему реакт жутко динамический: для того чтобы скрыть слово advertisements от блокировщиков рекламы, фронты идут на жуткие махинации с дом нодами
🚀🚀
поэтому если вы продаёте рекламу, то форест не для вас. тут аналогично
https://t.me/effector_ru/134991
https://t.me/effector_ru/134991
🚀🚀
обращаю ещё раз внимание, что эти фичи с хэндлерами не взаимоисключающие
NF
это как аргументация почему реакт жутко динамический: для того чтобы скрыть слово advertisements от блокировщиков рекламы, фронты идут на жуткие махинации с дом нодами
use gifts))
🚀🚀
проще говоря, я не хочу равнять все ситуации по наихудшему общему знаменателю
🚀🚀
и правильно твой вопрос звучит как «почему таких опциональных возможностей не было в дом апи изначально»
🚀🚀
once есть, capture есть, а prevent нет
🚀🚀
к — консистентность
NF
типа не реклама, а предложение, не акции и скидки, а подарки, это кстати хорошо работает даже в плане того как выглядит ui, вместо большой красной надписи "скидка 20%" если нарисовать коробки подарков то это более привлекательно для клиентов
NF
prevent зависит от логики обработчика, а не от предмета обработки
NF
в этом есть логика имхо
🚀🚀
вот именно что зависит от предмета обработки
🚀🚀
я хотел привести пример, но, внезапно, он изначально обсуждался
🚀🚀
я хз зачем ты упираешься, submit форм по дефолту запревенчен если ты делаешь свою обработку формы
🚀🚀
тут не нужна логика
🚀🚀
и есть одно наблюдение