@idrmn а @change не походит?

:D

Вотчить?))

как вар

Ему запрос по событию посылать надо. Как v-model тут поможет?

watch

2 глава, про патерн синхронизации, кому там нужно было.

Бред

как вар

Хероватый вар

Давайте вотчить кнопки

watch

фигня.

Йеа)

@idrmn а @change не походит?

Это тоже самое))))

ок, двайте останемся каждый при своем мнении)

watch

Вы ведь в курсе, что v-model = @input + $emit ?

нет, не знал, спасибо

ок, двайте останемся каждый при своем мнении)

Вот у меня сегодня - 124 инпута!! 124!!!!

Вотчить?... Увольте.

Ну, привет вашим UXерам)

@idrmn не до конца) Все же @change - ваш собственный обработчик. Хотя на сколько мне известно, то можно get, set написать для конретного data

v-model

V-model не это неявное указание на отлов события @update

@idrmn не до конца) Все же @change - ваш собственный обработчик. Хотя на сколько мне известно, то можно get, set написать для конретного data

Это сахар

@idrmn вы об @change?

v-model - это же v-bind и v-on, нет?

нет, не знал, спасибо

Это синтаксический сахар для события и пропса. https://ru.vuejs.org/v2/guide/components.html#Поля-ввода-форм-с-использованием-пользовательских-событий

v-model - это же v-bind и v-on, нет?

v-on:update

Это важно

v-on:update

input

input

input

Ой бля, точно

Ой бля, точно

это .sync :)

v-on:update

*v-on:input

это .sync :)

Думаю об одном, пишу о другом 🤦‍♂

Пора спать

Это да

Определённо, пора спать

У меня жена также )

Кто чекнет статейку мою, о Vuex :)

Ссылку в студию

V-model не это неявное указание на отлов события @update

V-model это бинд и эмит. А уж собитие и пропс можно какой угодно повесить

V-model это бинд и эмит. А уж собитие и пропс можно какой угодно повесить

Бинд и листенер

Вы ведь в курсе, что v-model = @input + $emit ?

@input и :value

V-model это бинд и эмит. А уж собитие и пропс можно какой угодно повесить

Определяется в дочерней компоненте

@input и :value

Аргх, да

@input и :value

По дефолту.поменять можно на что угодно

@idrmn вы об @change?

Конечно

По дефолту.поменять можно на что угодно

кэп

По дефолту.поменять можно на что угодно

но я б не стал

Аргх, да

И тебе пора спать

:В

но я б не стал

ну чтоб чекбокс менять на change и меняют

Ну, привет вашим UXерам)

Это зависимости с чайлдами. Как было когда то (а может и есть) на фл.ру Типа категории и подкатегории

ну чтоб чекбокс менять на change и меняют

А, ну только есть чекбокс. Я про компоненты подумал

А еще можно на на нативном инпуте сделать v-model с отправкой запроса в сеть. И вотчи не надо. И события отдельно слушать тоже не нужно. Вопрос тольк ов том, подойдет ли такое решение в контексте задачи)

А еще можно на на нативном инпуте сделать v-model с отправкой запроса в сеть. И вотчи не надо. И события отдельно слушать тоже не нужно. Вопрос тольк ов том, подойдет ли такое решение в контексте задачи)

эт чтоб запрос на каждый чих отправлялся? совсем сервер не жалко?

Фильтровать никто не мешает

Ставить в очерель также

А еще можно юзать готовые либо UI для Vue

iView например 😉

Ну и да, в целом так себе решение по изменению инпута менять фильтры по сети

100500 раз уже всеми изучено и проклято)

А еще можно на на нативном инпуте сделать v-model с отправкой запроса в сеть. И вотчи не надо. И события отдельно слушать тоже не нужно. Вопрос тольк ов том, подойдет ли такое решение в контексте задачи)

Ммм как а то я не доганяю))?

В дата впихнуть функцию?))

v-model = v-bind:value + $emit('input') Соответсвенно, слушаем change, по нему отправляем сетевой запрос и эмитим input

Получаем то же самое + отправку по сети

v-model = v-bind:value + $emit('input') Соответсвенно, слушаем change, по нему отправляем сетевой запрос и эмитим input

Какой-то чекбокс с побочными эффектами) Тыкнули галку, а он сам отправил запрос.

v-model = v-bind:value + $emit('input') Соответсвенно, слушаем change, по нему отправляем сетевой запрос и эмитим input

Не. Ну это тоже самое.

А еще есть model: { prop: 'checked', event: 'change' },

Какой-то чекбокс с побочными эффектами) Тыкнули галку, а он сам отправил запрос.

Так вроде этого и хотят, поправьте если ошибаюсь

Так вроде этого и хотят, поправьте если ошибаюсь

Да, но не таким неявным способом. Я выше писал про "умные" и "глупые" компоненты.

Я прекрасно знаю, что это. Мало того, когда есть стор, такая концепция сама собой появится иначе поддержка проекта умрет

Вопрос в том, что никто не запрещает так сделать. И это еще одно решение. Собственно, поэтому Vue и набирает обороты - в нем можно (почти) все.

Вопрос в том, что никто не запрещает так сделать. И это еще одно решение. Собственно, поэтому Vue и набирает обороты - в нем можно (почти) все.

Можно, конечно. Но опять же, повторюсь, не очень хорошее решение, имхо.

Ну, кстати, чем это не умный компонент?

Ну, кстати, чем это не умный компонент?

Так а зачем его умным делать?

Чтобы не делать кучу копипаста, например

ну вот сейчас вот получил от Vue Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "active"

Если будет несколько страниц, которые будут управлять набором вот таких чекбоксов с запросами в сеть, поулчите проблему дублирования логики.

сделал v-model vprops-a

@obsly так низя)

Если будет несколько страниц, которые будут управлять набором вот таких чекбоксов с запросами в сеть, поулчите проблему дублирования логики.

Как раз таки не будет копипасы, потому что это будет в одном компоненте - родителе

"умном" родителе

т е таки надо делать отдельную дату для состояния, потом слать его на сервак потом если 200 то обновлять пропс?

Вы меняете пропс изнутри, а это нарушение цепочки пропсы-сверху, эвенты-снизу