Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Можно:)
Задача: - Сделать строку поиска - Введенные значения отправляются на сервер и результаты отдаются на фронт
РЕШЕНИЕ 1. Делать через computed: - реагировать на изменение значения в поиске - отправлять запрос на сервер ТАК НЕЛЬЗЯ делать и это и назвал извращением, потому что computed не для того создан.
РЕШЕНИЕ 2. Делать через computed, но при этом computed - лишь часть логики, которая будет выглядеть как: - ввели значение в строке поиска: сработала v-model - среагировали вотчером на изменение значения переменной - записали полученные с сервера данные в новую переменную - обработали результаты поиска в computed
Как-то много телодвижений...
РЕШЕНИЕ 3. Метод на событие input элемента / компонента строки поиска: - ввели значение в строке поиска - среагировали на событие элемента / компонента - отправили запрос (1 функция) - обработали данные в методе и записали в переменную результата (2-ая функция внутри первой функции)
Расходов на понимание со стороны разработчика и обслуживание кода со стороны движка получается много меньше и для разработчика много понятнее "что откуда и куда" берётся без распутывания цепочки с вотчерами и компьютедами, т.к. всё стало более явно, а явное всегда лучше.
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы .
Если вам это очевидно - ну ок :) Из-за таких "это же очевидно" потом и возникают "а я думал вы поняли / имели это в виду". Нет, не очевидно, если об этом не сказано прямо. Да и косвенных тому намёков нет. Если вы угадали, что это про валидацию, могу только порадоваться вашей догадливости.
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло.
Я четко написал задание: валидировать форму при сабмите, а это значит, что требование, чтобы пользователь видел ошибки только после клика на сабмит.. Но возникает вопрос: зачем валидировать через computed, если это можно сделать 1 раз при клике на сабмит, если пользователь узнает о состоянии валидации только при клике на сабмит? Вы предлагаете computed и я не говорю, что это решение плохое - вполне нормальное, но я лишь говорю что дешевле сделать то же самое методом.
очевидно у вас возникнут проблемы с перфом из-за валидации формы
всё зависит от конкретной ситуации, ведь это может быть как форма на 2 инпута, так и форма, состоящая из десятков, а то и сотен полей (привет no-code / low-code конструкторы) и вот получили тормозного монстра, потому что computed обсчитывает валидацию на каждый чих в форме, поэтому каждой задаче своё решение и постулировать "В реальной жизни, к счастью, никто не следит на событиями элементов формы в vue, особенно в рамках валидации полей " не стоит. Как уже видно из примеров выше, следим когда это требуется.
Не было контекста про валидацию, равно как и был пример в статье про поиск. Это уже ваше сообщение про валидацию и, если говорить только о валидации или чем-то другом - уход от общего к частному, что вы и делаете. Речь же о более широком использовании.
И да, я не против computed для обработки валидации, но опять же это не всегда уместно - зависит от требований: вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен.
Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение
Можно писать на js так же: с подсветкой ошибок и выводом их в консоль, + подсказки работают в ide, только не будет крашиться приложение, если тип ошибочен.
Это достигается связкой Ts + jsdock + включенная валидация js в vs code
Но! При этом мы пишем js, а не ts и не имеем той массы условностей и многословности, которые заставляет нас делать ts
Ts установлен в dev dep и служит для того для чего и нужен: сопоставляет типы
Пожалуйста, старайтесь использовать shallowmount и только потом mount, когда он реально нужен или без него никак не получается, т.к. это убережет от кучи проблем, связанных с mount, аля "сломалось что-то на 3-4 уровня вниз, а падает именно этот тест и теперь ищи и разбирайся почему".
Не понятна проблема стабать состояние компонента ui? Он же по дефолту имеет значения пропсов и в тестируемом компоненте он маунтится именно с дефолтным состоянием изначально. Если же нет, то надо понимать откуда берется это состояние: - если из глобального стейта, то перед выполнение теста установить нужное значение в стейте - если в ходе работы логики тестируемого компонента - вообще не стоит переживать, т.к. это поведение компонента и это даже можно протестировать - если хардкодом прописано значение пропса - можно стабать вручную
Но, в любом случае, по возможности, надо стараться по минимуму стабать руками компоненты, т.к. это несет много банальных рисков: "добавили фичу / исправили баг в компоненте, а тест не обновили".
Зачем стабать вручную дочерние компоненты, если это уже сделал shallowmount? Если это только из-за слота, так дефолтный слот можно рендерить с помощью renderStubDefaultSlot
Без явной необходимости не стоит стабать вручную дочерний компонент и не будет (почти) проблем в будущем при измении их контрактов, потому что тест будет смотреть на реальную реализацию компонента, а не его ручной стаб в тесте.
Имхо. Очень мало ситуаций когда надо стабать вручную компоненты. Как пример на скорую мысль, приходит только: у тестируемой сущности нет четкого шаблона (тесты в ядре vue) или надо настабать не дефолтные слоты, что может решиться использованием mount, а не shallowmount.
Сброс моков: для примера это ок, чтобы наглядно было, но в проекте это можно вынести в глобальную область, т.к., когда 1 компонент, это всё интересно и прикольно, но, когда из раза в раз приходится писать, утомляет. Это вкусовщина, на самом деле. Упоминаю на всякий случай: вдруг не в курсе возможности и это можно описать отдельным абзацем на самом деле.
Часть импортов из vitest можно не делать: работает по дефолту, т.к. всегда доступно в тестах, если настроить vite.config
Мы решили это так: если есть какой-то компонент локальный для сущности слоя, то структура будет, например: entities/parent-component/components/child-component, где child-component, в свою очередь, будет иметь свои папки (utils, store, styles и т.д.). Таким образом получается, что сущности, которые точно не переиспользуемые, не размазываются по приложению.
Да, это не чистый fsd, но и в доке написано, что её может потребоваться модифицировать. Зато это даёт как свободу и переиспользуемость fsd, а также снижает порог входа для новых разработчиков (или старых тех кто с каким-то модулем столкнётся впервые).
Ставил я, значится, для ckeditor и билд и не билд... результат один: ругается на уже подключенный модуль. А я всего лишь хотел иметь возможность подключать только нужные плагины, но пришлось отложить до "будет время - поковыряю еще"
Не бывает ситуаций, когда нужно использовать <component :is="componentName"> и нужно задать разные пропсы компонентам или кто-то злоупотребляет этим?
Если бывают, то как в таких ситуациях поступаете: 1.пишете портянку v-if/v-else-if или 2. указываете пропс <component is= "" :props1 :props2 ...> без оглядки нужен он компоненту или нет?
Event-bus - мега не очевидно. provide/inject - тоже, но в меньшей степени.
В большом проекте надо постараться, чтобы найти родителя в котором сделан provide. Можно ставить коммент, как вариант, у inject, но родителя перенесли/переименовали и финита ля комедия - ищи снова родителя.
Сам я использовал provide/inject и это удобно, но это был маленький проект и там было всё очевидно. В больших проектах лучше искать более удобные решения, даже если это "велосипеды"
Все плюсы и минусы описаны в доке. Весь проект можно писать на ref и reactive вообще не использовать.
Зато синтакис property.value, в подавляющем большинстве случаев, сразу будет говорить о том, что используется реактивная переменная, а не что-то еще.
Можно, пожалуйста, хотя-бы один аргумент про удобство и почему это - извращение?
Можно:)
Задача:
- Сделать строку поиска
- Введенные значения отправляются на сервер и результаты отдаются на фронт
РЕШЕНИЕ 1. Делать через computed:
- реагировать на изменение значения в поиске
- отправлять запрос на сервер
ТАК НЕЛЬЗЯ делать и это и назвал извращением, потому что computed не для того создан.
РЕШЕНИЕ 2. Делать через computed, но при этом computed - лишь часть логики, которая будет выглядеть как:
- ввели значение в строке поиска: сработала v-model
- среагировали вотчером на изменение значения переменной
- записали полученные с сервера данные в новую переменную
- обработали результаты поиска в computed
Как-то много телодвижений...
РЕШЕНИЕ 3. Метод на событие input элемента / компонента строки поиска:
- ввели значение в строке поиска
- среагировали на событие элемента / компонента - отправили запрос (1 функция)
- обработали данные в методе и записали в переменную результата (2-ая функция внутри первой функции)
Расходов на понимание со стороны разработчика и обслуживание кода со стороны движка получается много меньше и для разработчика много понятнее "что откуда и куда" берётся без распутывания цепочки с вотчерами и компьютедами, т.к. всё стало более явно, а явное всегда лучше.
Вы же, напротив, зачем-то уходите к общему случаю, когда тут очевидно речь о валидации формы .
Если вам это очевидно - ну ок :) Из-за таких "это же очевидно" потом и возникают "а я думал вы поняли / имели это в виду". Нет, не очевидно, если об этом не сказано прямо. Да и косвенных тому намёков нет. Если вы угадали, что это про валидацию, могу только порадоваться вашей догадливости.
Вероятнее валидировать придется на событии change, либо в режиме realtime, раз уж на то пошло.
Я четко написал задание: валидировать форму при сабмите, а это значит, что требование, чтобы пользователь видел ошибки только после клика на сабмит..
Но возникает вопрос: зачем валидировать через computed, если это можно сделать 1 раз при клике на сабмит, если пользователь узнает о состоянии валидации только при клике на сабмит? Вы предлагаете computed и я не говорю, что это решение плохое - вполне нормальное, но я лишь говорю что дешевле сделать то же самое методом.
очевидно у вас возникнут проблемы с перфом из-за валидации формы
всё зависит от конкретной ситуации, ведь это может быть как форма на 2 инпута, так и форма, состоящая из десятков, а то и сотен полей (привет no-code / low-code конструкторы) и вот получили тормозного монстра, потому что computed обсчитывает валидацию на каждый чих в форме, поэтому каждой задаче своё решение и постулировать "В реальной жизни, к счастью, никто не следит на событиями элементов формы в vue, особенно в рамках валидации полей " не стоит. Как уже видно из примеров выше, следим когда это требуется.
Не было контекста про валидацию, равно как и был пример в статье про поиск. Это уже ваше сообщение про валидацию и, если говорить только о валидации или чем-то другом - уход от общего к частному, что вы и делаете. Речь же о более широком использовании.
И да, я не против computed для обработки валидации, но опять же это не всегда уместно - зависит от требований: вероятно валидировать нужно всего 1 раз при нажатии на сабмит и тогда предпочтительней будет метод, а не вычисляемое свойство, которое запускается на каждое изменение, ведь computed не бесплатен.
"Не валидацией единой живем"
Согласен с предыдущим оратором, т.к. не валидацией единой живем. Тот же запрос при вводе в поле поиска удобнее сделать через событие элемента, а не через вотчеры. И computed тут вообще никак не поможет.
p.s. при желании можно и через него сделать, но это извращение
Нет проблем: вызываем файл в PowerShell (./createPage.sh) или через терминал гита.
Тоже написал баш скрипт для генерации новой страницы: папки, файлы с нужными импортами, константами, подключениями и т.д.
Можно писать на js так же: с подсветкой ошибок и выводом их в консоль, + подсказки работают в ide, только не будет крашиться приложение, если тип ошибочен.
Это достигается связкой Ts + jsdock + включенная валидация js в vs code
Но! При этом мы пишем js, а не ts и не имеем той массы условностей и многословности, которые заставляет нас делать ts
Ts установлен в dev dep и служит для того для чего и нужен: сопоставляет типы
Пожалуйста, старайтесь использовать shallowmount и только потом mount, когда он реально нужен или без него никак не получается, т.к. это убережет от кучи проблем, связанных с mount, аля "сломалось что-то на 3-4 уровня вниз, а падает именно этот тест и теперь ищи и разбирайся почему".
Не понятна проблема стабать состояние компонента ui? Он же по дефолту имеет значения пропсов и в тестируемом компоненте он маунтится именно с дефолтным состоянием изначально. Если же нет, то надо понимать откуда берется это состояние:
- если из глобального стейта, то перед выполнение теста установить нужное значение в стейте
- если в ходе работы логики тестируемого компонента - вообще не стоит переживать, т.к. это поведение компонента и это даже можно протестировать
- если хардкодом прописано значение пропса - можно стабать вручную
Но, в любом случае, по возможности, надо стараться по минимуму стабать руками компоненты, т.к. это несет много банальных рисков: "добавили фичу / исправили баг в компоненте, а тест не обновили".
Несколько моментов за которые зацепился глаз:
Зачем стабать вручную дочерние компоненты, если это уже сделал shallowmount? Если это только из-за слота, так дефолтный слот можно рендерить с помощью renderStubDefaultSlot
Без явной необходимости не стоит стабать вручную дочерний компонент и не будет (почти) проблем в будущем при измении их контрактов, потому что тест будет смотреть на реальную реализацию компонента, а не его ручной стаб в тесте.
Имхо. Очень мало ситуаций когда надо стабать вручную компоненты. Как пример на скорую мысль, приходит только: у тестируемой сущности нет четкого шаблона (тесты в ядре vue) или надо настабать не дефолтные слоты, что может решиться использованием mount, а не shallowmount.
Сброс моков: для примера это ок, чтобы наглядно было, но в проекте это можно вынести в глобальную область, т.к., когда 1 компонент, это всё интересно и прикольно, но, когда из раза в раз приходится писать, утомляет. Это вкусовщина, на самом деле. Упоминаю на всякий случай: вдруг не в курсе возможности и это можно описать отдельным абзацем на самом деле.
Часть импортов из vitest можно не делать: работает по дефолту, т.к. всегда доступно в тестах, если настроить vite.config
Мы решили это так: если есть какой-то компонент локальный для сущности слоя, то структура будет, например: entities/parent-component/components/child-component, где child-component, в свою очередь, будет иметь свои папки (utils, store, styles и т.д.). Таким образом получается, что сущности, которые точно не переиспользуемые, не размазываются по приложению.
Да, это не чистый fsd, но и в доке написано, что её может потребоваться модифицировать. Зато это даёт как свободу и переиспользуемость fsd, а также снижает порог входа для новых разработчиков (или старых тех кто с каким-то модулем столкнётся впервые).
Ставил я, значится, для ckeditor и билд и не билд... результат один: ругается на уже подключенный модуль. А я всего лишь хотел иметь возможность подключать только нужные плагины, но пришлось отложить до "будет время - поковыряю еще"
Хм... этот момент я как-то упустил про v-bind:foo. Спасибо за ответ!
Почему используется
'vue/v-bind-style': 'error?Не бывает ситуаций, когда нужно использовать
<component :is="componentName">и нужно задать разные пропсы компонентам или кто-то злоупотребляет этим?Если бывают, то как в таких ситуациях поступаете: 1.пишете портянку
v-if/v-else-ifили 2. указываете пропс<component is= "" :props1 :props2 ...>без оглядки нужен он компоненту или нет?Event-bus - мега не очевидно. provide/inject - тоже, но в меньшей степени.
В большом проекте надо постараться, чтобы найти родителя в котором сделан provide. Можно ставить коммент, как вариант, у inject, но родителя перенесли/переименовали и финита ля комедия - ищи снова родителя.
Сам я использовал provide/inject и это удобно, но это был маленький проект и там было всё очевидно. В больших проектах лучше искать более удобные решения, даже если это "велосипеды"
Стресс в любой сфере есть. В продажах он не меньше, у таксиста не меньше. Почему в ит так прижилось "тут стресса..."...
Мне есть с чем сравнить, а потому не понимаю, когда говорят, что стресс в ит особенный. Сегодня он везде
А как же переиспользование кода в таком случае?
Ведь бывает, что 2 кнопки, с похожим функционалом, используют одни и те же куски кода и в таком случае дублировать код в каждую надо