Комментарии 15
Всё конечно хорошо, только в реальной жизни, без везкой причины, от watch и watchEffect, лучше отказатся.
Ваши примеры тому подтверждение, вы сделали их через слежение, просто потому, что можете. Всё это делается через событие элементов формы, что в дальнейшем проще дебажить.
В реальной жизни, к счастью, никто не следит на событиями элементов формы в vue, особенно в рамках валидации полей
Обычно есть computed, который сам вычисляет актуальный стейт валидации
Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение
У вас реактивность на сигналах, почему вы ей не пользуетесь?
Единственная причина, которую я могу понять - сложность в ее понимании
Вы буквально привязываете реактивный примитив к элементу формы, и тут computed напрашивается по всем законам логики
Когда мы говорим про асинхронную валидацию, то тут уже стоит подумать, что удобнее
К чему тут речь про поиск - я не очень понял, контекст все же про валидацию
Не было контекста про валидацию, равно как и был пример в статье про поиск. Это уже ваше сообщение про валидацию и, если говорить только о валидации или чем-то другом - уход от общего к частному, что вы и делаете. Речь же о более широком использовании.
И да, я не против computed для обработки валидации, но опять же это не всегда уместно - зависит от требований: вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен.
"Не валидацией единой живем"
Прочтите, пожалуйста, первый комментарий в треде:
"Всё это делается через событие элементов формы, что в дальнейшем проще дебажить."
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы
Вы написали:
"вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен."
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло. Некоторые еще любят блокировать кнопку submit, когда валидация не пройдена, что, конечно отвратительно с точки зрения UX. Тем не менее все эти кейсы замечательно работают с computed.
"ведь computed не бесплатен." - очевидно у вас возникнут проблемы с перфом из-за валидации формы =D.
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы .
Если вам это очевидно - ну ок :) Из-за таких "это же очевидно" потом и возникают "а я думал вы поняли / имели это в виду". Нет, не очевидно, если об этом не сказано прямо. Да и косвенных тому намёков нет. Если вы угадали, что это про валидацию, могу только порадоваться вашей догадливости.
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло.
Я четко написал задание: валидировать форму при сабмите, а это значит, что требование, чтобы пользователь видел ошибки только после клика на сабмит..
Но возникает вопрос: зачем валидировать через computed, если это можно сделать 1 раз при клике на сабмит, если пользователь узнает о состоянии валидации только при клике на сабмит? Вы предлагаете computed и я не говорю, что это решение плохое - вполне нормальное, но я лишь говорю что дешевле сделать то же самое методом.
очевидно у вас возникнут проблемы с перфом из-за валидации формы
всё зависит от конкретной ситуации, ведь это может быть как форма на 2 инпута, так и форма, состоящая из десятков, а то и сотен полей (привет no-code / low-code конструкторы) и вот получили тормозного монстра, потому что computed обсчитывает валидацию на каждый чих в форме, поэтому каждой задаче своё решение и постулировать "В реальной жизни, к счастью, никто не следит на событиями элементов формы в vue, особенно в рамках валидации полей " не стоит. Как уже видно из примеров выше, следим когда это требуется.
В целом, теперь мне стало яснее ваше мнение, и я с ним почти полностью согласен
Я постулировал, что в огромнейшем большинстве случаев формы не мунструозные, и смысла от погони за мнимым перфом нет.
Автор комментария вообще написал "Всё конечно хорошо, только в реальной жизни, без везкой причины, от watch и watchEffect, лучше отказатся."
И это уже выдумки автора комментария, и описал он контекст своей фразы во втором абзаце, когда сказал про элементы формы.
"Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение"
Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Есть масса способов сделать это нормально без подписки на событие инпута, и пример в статье абсолютно нормальный с поиском.
Вопрос снимается, тут я уже вас неправильно понял =D
Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Можно:)
Задача:
- Сделать строку поиска
- Введенные значения отправляются на сервер и результаты отдаются на фронт
РЕШЕНИЕ 1. Делать через computed:
- реагировать на изменение значения в поиске
- отправлять запрос на сервер
ТАК НЕЛЬЗЯ делать и это и назвал извращением, потому что computed не для того создан.
РЕШЕНИЕ 2. Делать через computed, но при этом computed - лишь часть логики, которая будет выглядеть как:
- ввели значение в строке поиска: сработала v-model
- среагировали вотчером на изменение значения переменной
- записали полученные с сервера данные в новую переменную
- обработали результаты поиска в computed
Как-то много телодвижений...
РЕШЕНИЕ 3. Метод на событие input элемента / компонента строки поиска:
- ввели значение в строке поиска
- среагировали на событие элемента / компонента - отправили запрос (1 функция)
- обработали данные в методе и записали в переменную результата (2-ая функция внутри первой функции)
Расходов на понимание со стороны разработчика и обслуживание кода со стороны движка получается много меньше и для разработчика много понятнее "что откуда и куда" берётся без распутывания цепочки с вотчерами и компьютедами, т.к. всё стало более явно, а явное всегда лучше.
Касаемо конкретно валидации, чаще всего у вас в проекте есть готовое решение для валидации полей, либо своё кастомное, либо какой нибудь open-source(например vuelidate).
А даже если его нет, использовать события формы - более гибкое решение.
Хорошая статья для не погруженных, спасибо
у Watch есть опция flush, которая очень важна для понимания, но в статье не упомянута, как и watchPostEffect, watchSyncEffect
также, есть 3й аргумент эффекта watch onCleanup (у watchEffect он первый), который выполняется когда эффект хочет отработать еще раз, и очень полезен в случаях, когда нам может понадобиться заново запросить какие-то данные, а старый запрос отменить с AbortController
Также, имхо, стоит добавить про то, как watch и watchEffect собирают реактивные зависимости, для выполнения эффекта, ибо это дает чуть больше понимания инструмента, а также может объяснить новичкам, почему этот код работает так, как он работает
Еще можно добавить про то, почему watch не уничтожаются, когда мы юзаем композабл не внутри setup, а внутри какого-нибудь метода (effect scope)
Vue. Watch и WatchEffect на практике