Size: a a a

2020 August 04

АБ

Александр Бакиматов... in ☄️ effector
нам ток политоты не хватало да)
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
подключение в ui эвента который работает как команда для обновления стора даёт краткость записи, это тоже бывает важно, когда код не планируется интенсивно расширять или использовать в сложном бизнес-процессе
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Александр Бакиматов
нам ток политоты не хватало да)
я слежу за этим)
источник

YL

Yan👀 Lobaty in ☄️ effector
🅅aleriy 🄺obzar
store.on должен выполнять приказы от эвентов в повелительном наклонении
Нет
Store среагировал на (.on) уже случившиеся событие
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Yan👀 Lobaty
Нет
Store среагировал на (.on) уже случившиеся событие
не всегда
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Yan👀 Lobaty
Нет
Store среагировал на (.on) уже случившиеся событие
глянь статью) я там как раз пишу про это, чтобы прояснить ситуацию

https://t.me/effector_ru/150386
источник

DS

Dmitriy Shuleshov in ☄️ effector
🚀🔬 🚀🔬🚀🔬
подключение в ui эвента который работает как команда для обновления стора даёт краткость записи, это тоже бывает важно, когда код не планируется интенсивно расширять или использовать в сложном бизнес-процессе
https://share.effector.dev/bnnC6D7o

Поставлю вопрос по другому. Если бы пришли на проект где я нафигачил вот таким подходом много кода, что у вас вызвало бы отторжение или недопонимание?

@doasync @sovasergey @lobatik
источник

P

Paruyr🛸🪐🌏 in ☄️ effector
Event из DOM это относиться ко View
на мой взгляд надо во View стрелку, которая собирает нужные данные из нативного ивента и передает в ивент эффектора
те onChange={e => emailChanged(e.target.value)}
источник

n

null in ☄️ effector
Paruyr🛸🪐🌏
Event из DOM это относиться ко View
на мой взгляд надо во View стрелку, которая собирает нужные данные из нативного ивента и передает в ивент эффектора
те onChange={e => emailChanged(e.target.value)}
Согласен
источник

🦜

🦜 in ☄️ effector
Paruyr🛸🪐🌏
Event из DOM это относиться ко View
на мой взгляд надо во View стрелку, которая собирает нужные данные из нативного ивента и передает в ивент эффектора
те onChange={e => emailChanged(e.target.value)}
так пока email в сторе не поменялся, то событие то и не произошло, оно происходит во время ввода, а когда ввод завершен, тогда stores.updates это и есть emailChanged
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Paruyr🛸🪐🌏
Event из DOM это относиться ко View
на мой взгляд надо во View стрелку, которая собирает нужные данные из нативного ивента и передает в ивент эффектора
те onChange={e => emailChanged(e.target.value)}
такую же трансформацию можно делать и мапом эвентов, то есть это не тот признак, который бы как-то характеризовал ui эвенты
источник

n

null in ☄️ effector
Я думаю, что в модель должны попадать данные, которые можно потом не трансформировать. Если можно сразу вытащить текст на дом ивента и отправить в модель, то почему бы так и не сделать
источник

ф

фильтруй мысли... in ☄️ effector
Dmitriy Shuleshov
https://share.effector.dev/bnnC6D7o

Поставлю вопрос по другому. Если бы пришли на проект где я нафигачил вот таким подходом много кода, что у вас вызвало бы отторжение или недопонимание?

@doasync @sovasergey @lobatik
это ужасно, то что я увидел 😟
источник

DS

Dmitriy Shuleshov in ☄️ effector
фильтруй мысли
это ужасно, то что я увидел 😟
Есть конкретика?
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Dmitriy Shuleshov
https://share.effector.dev/bnnC6D7o

Поставлю вопрос по другому. Если бы пришли на проект где я нафигачил вот таким подходом много кода, что у вас вызвало бы отторжение или недопонимание?

@doasync @sovasergey @lobatik
не очень понимаю смысл префикса handle, если оставшаяся часть названия даёт понять что это intention

абстракция из ui протекла в бизнес-логику: смысл разделения эвента на два в том чтобы логика обновления email не знала о деталях дом апи типа target.value, а дублирование этой конструкции дважды окончательно даёт понять: разделение было произведено в неверной точке

если ты хочешь показать что ui эвент явно подключен к эвенты бизнес логики то можно использовать prepend

const emailInputChanged = changeEmail.prepend(
 e => e.target.value
)
источник

P

Paruyr🛸🪐🌏 in ☄️ effector
changeEmail должен быть определен во View?
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
null
Я думаю, что в модель должны попадать данные, которые можно потом не трансформировать. Если можно сразу вытащить текст на дом ивента и отправить в модель, то почему бы так и не сделать
я бы сказал немного не так: трансформацию данных можно расположить в модели если она — часть бизнес-процессов а не деталь извлечения информации из ui
источник

n

null in ☄️ effector
🚀🔬 🚀🔬🚀🔬
я бы сказал немного не так: трансформацию данных можно расположить в модели если она — часть бизнес-процессов а не деталь извлечения информации из ui
хорошее уточнение
источник

🦜

🦜 in ☄️ effector
🚀🔬 🚀🔬🚀🔬
я бы сказал немного не так: трансформацию данных можно расположить в модели если она — часть бизнес-процессов а не деталь извлечения информации из ui
ну т.е выше компонента или внутри компонента надо писать функции handler
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Paruyr🛸🪐🌏
changeEmail должен быть определен во View?
подразумевается что changeEmail это команда на обновление стора $email, то есть наоборот сущность которая никак не связана с ui
источник