"Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение"
Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Есть масса способов сделать это нормально без подписки на событие инпута, и пример в статье абсолютно нормальный с поиском.
"Всё это делается через событие элементов формы, что в дальнейшем проще дебажить."
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы
Вы написали: "вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен."
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло. Некоторые еще любят блокировать кнопку submit, когда валидация не пройдена, что, конечно отвратительно с точки зрения UX. Тем не менее все эти кейсы замечательно работают с computed.
"ведь computed не бесплатен." - очевидно у вас возникнут проблемы с перфом из-за валидации формы =D.
у Watch есть опция flush, которая очень важна для понимания, но в статье не упомянута, как и watchPostEffect, watchSyncEffect
также, есть 3й аргумент эффекта watchonCleanup (у watchEffect он первый), который выполняется когда эффект хочет отработать еще раз, и очень полезен в случаях, когда нам может понадобиться заново запросить какие-то данные, а старый запрос отменить с AbortController
Также, имхо, стоит добавить про то, как watch и watchEffect собирают реактивные зависимости, для выполнения эффекта, ибо это дает чуть больше понимания инструмента, а также может объяснить новичкам, почему этот код работает так, как он работает
Еще можно добавить про то, почему watch не уничтожаются, когда мы юзаем композабл не внутри setup, а внутри какого-нибудь метода (effect scope)
Я понял, я про другое подумал
Согласен, этот кейс реально будет извращением
Вопрос снимается, тут я уже вас неправильно понял =D
В целом, теперь мне стало яснее ваше мнение, и я с ним почти полностью согласен
Я постулировал, что в огромнейшем большинстве случаев формы не мунструозные, и смысла от погони за мнимым перфом нет.
Автор комментария вообще написал "Всё конечно хорошо, только в реальной жизни, без везкой причины, от watch и watchEffect, лучше отказатся."
И это уже выдумки автора комментария, и описал он контекст своей фразы во втором абзаце, когда сказал про элементы формы.
"Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение"
Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Есть масса способов сделать это нормально без подписки на событие инпута, и пример в статье абсолютно нормальный с поиском.
Прочтите, пожалуйста, первый комментарий в треде:
"Всё это делается через событие элементов формы, что в дальнейшем проще дебажить."
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы
Вы написали:
"вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен."
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло. Некоторые еще любят блокировать кнопку submit, когда валидация не пройдена, что, конечно отвратительно с точки зрения UX. Тем не менее все эти кейсы замечательно работают с computed.
"ведь computed не бесплатен." - очевидно у вас возникнут проблемы с перфом из-за валидации формы =D.
у
Watchесть опцияflush, которая очень важна для понимания, но в статье не упомянута, как иwatchPostEffect,watchSyncEffectтакже, есть 3й аргумент эффекта
watchonCleanup (у watchEffect он первый), который выполняется когда эффект хочет отработать еще раз, и очень полезен в случаях, когда нам может понадобиться заново запросить какие-то данные, а старый запрос отменить с AbortControllerТакже, имхо, стоит добавить про то, как
watchиwatchEffectсобирают реактивные зависимости, для выполнения эффекта, ибо это дает чуть больше понимания инструмента, а также может объяснить новичкам, почему этот код работает так, как он работаетЕще можно добавить про то, почему
watchне уничтожаются, когда мы юзаем композабл не внутриsetup, а внутри какого-нибудь метода (effect scope)"Мнимая гибкость" - единственный аргумент, который здесь может быть для вас
Причем она вам понадобится буквально в 5% случаев, и будет всегда являться корнер-кейсом, когда вы откажитесь от реактивности в пользу линейной логики
У вас реактивность на сигналах, почему вы ей не пользуетесь?
Единственная причина, которую я могу понять - сложность в ее понимании
Вы буквально привязываете реактивный примитив к элементу формы, и тут computed напрашивается по всем законам логики
Когда мы говорим про асинхронную валидацию, то тут уже стоит подумать, что удобнее
К чему тут речь про поиск - я не очень понял, контекст все же про валидацию
В реальной жизни, к счастью, никто не следит на событиями элементов формы в vue, особенно в рамках валидации полей
Обычно есть computed, который сам вычисляет актуальный стейт валидации