Ну набросай на жсфиддл пример

Ну набросай на жсфиддл пример

Дома буду - кину

Давай

Минимум через 30 мин карочи

а можно как то вызвать метод дочернего компонента из родительского?

а можно как то вызвать метод дочернего компонента из родительского?

Нет

совсем?

Точнее можно, но я не скажу

Ибо это не нужно

почему?)

Потому что это плохо

Потому что рафик тупой

Хыхы

Шутка

Через $refs можно

А можно менять пропсы и вотчить их, как он хочет, но это бред, как по мне

пасиб

Типо зачем ты тогда компоненту вынес?

Потому что рафик тупой

Давай без этого, мы оба знаем, что я лучше

Давай без этого, мы оба знаем, что я лучше

Мы оба знаем, что apify не очень

Мы оба знаем, что apify не очень

Да все ей пользуются

Например я пользуюсь

а что это такое? =)

И все на этом?)

Через $refs можно

Вот этот метод точно говно

Лучше через пропсу

Вот этот метод точно говно

Лучше писать все в женском роде

В пропсу кстати можно сразу функцию передать

И пофиг, что это средний

В пропсу кстати можно сразу функцию передать

еге?

Стора, пропса, компонента Горю

Стора, пропса, компонента Горю

Угу, имянно

Азаза)00))

В пропсу кстати можно сразу функцию передать

И этот человек говорит мне, что $refs говно

А сам передаёт функции в пропсах

И этот человек говорит мне, что $refs говно

Рефс рили говно, это последняя линия обороны

Это как в штаны наложить

А сам передаёт функции в пропсах

В офф доках это даже есть

Ребята, а есть у кого то гтовый bolierplate на vue/vue-router/vuex?

Ребята, а есть у кого то гтовый bolierplate на vue/vue-router/vuex?

Vue cli webpack

Это нормальный способ не срать в штаны написанием логики, не относящейся к конкретному компоненту

А вообще, кстати Можно юзать model из 2.3

Vue cli webpack

токо вьюкс допом надо

Тогда не надо писать ничего лишнего

Вот этот вариант ещё норм

токо вьюкс допом надо

Как будто его сложно поставить

Вот этот вариант ещё норм

Единственно потом искать куда ты там ссылкаешься

Как будто его сложно поставить

да вон выше пишут, что сложна :)

Единственно потом искать куда ты там ссылкаешься

В appbar

Или что там у тебя оборачивает

А, layout

Да по большому счету нет большой разницы что юзать, синк или модель. И то, и другое синтаксический сахар для emit/prop

Это понятно, просто так короче

только v-model ты можешь обновлять одну переменную, а .sync много

А вообще вся эта логика должна храниться строго в sidebar Appbar не должен никак относиться к sidebar, он должен только дергать метод из него, но точно не эмитить/вотчить/ещё что-то делать Поэтому я считаю, что тут должно быть через $refs

только v-model ты можешь обновлять одну переменную, а .sync много

Ну тут имеется в виду одна, так что можно

А вообще вся эта логика должна храниться строго в sidebar Appbar не должен никак относиться к sidebar, он должен только дергать метод из него, но точно не эмитить/вотчить/ещё что-то делать Поэтому я считаю, что тут должно быть через $refs

С одной стороны я с тобой согласен, но с другой стороны у меня глаз дергается от $refs. Я бы наверное эмитил в контейнер и там уже просами спускал show/hide

веселый сегодня денек.... компонент получает массив данных через пропс...перебираю массив, вывожу нужное свойство...пусто...вывожу весь объект...выводится... ?

может просто хватит на сегодня кода? :)))

и ошибки главное не выводятся, типо что нет такого свойства...просто пустота

Да

не..ну как? :))

это же разрыв мозга :)

какую нибудь более сложную вещь делаешь...все ок...а тут упрешься в какую то мелочь и усё :)

Народ - vue - объектно-реактивное программирование реализует? Прост в последнее время на реакте писал - сейчас опять к вью вернулся - непривычно состояние мутировать - иммутабельность не очень хорошо у меня получается с ним применять

Никто так не загонялся?)

ERROR: S client not available

Че

Так не мутируй)

С одной стороны я с тобой согласен, но с другой стороны у меня глаз дергается от $refs. Я бы наверное эмитил в контейнер и там уже просами спускал show/hide

Ну да, у всех какая-то нездоровая реакция Но с точки зрения архитектуры здесь это правильнее

Ну у нас this все дела

Так не мутируй)

Может я совсем загнался)

Ну ты же везде заменяешь старое состояние новым

Из за обсервабла можно не возвращать новый объект, и я сегодня грешил этим немножко

Мб у меня задача специфичная просто)

Ну да, у всех какая-то нездоровая реакция Но с точки зрения архитектуры здесь это правильнее

Так хочеьтся сделать, потому что это очевидно и просто) Хорошего я в этом не вижу, ибо какой-то там метод делать что-то там сам в себе.

Хотел узнать - плохо ли мутировать стейт во вью (по идее нет, ибо даже во вьюксе мутации есть))

Из за обсервабла можно не возвращать новый объект, и я сегодня грешил этим немножко

Ну так просто возвращай)

Пока всё устраивает и работает без нареканий — не вижу проблем использованию

Так хочеьтся сделать, потому что это очевидно и просто) Хорошего я в этом не вижу, ибо какой-то там метод делать что-то там сам в себе.

Почитай про архитектуру и подумай, что ты написал сейчас

Почитай про архитектуру и подумай, что ты написал сейчас

ниче не понял, что ты написал

Хочется сделать не потому, что очевидно и просто, а потому, что appbar не относится к sidebar с какой стати в нем должна быть логика для него?

задача: нужно создать простой редактор

Ну так просто возвращай)

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

Хочется сделать не потому, что очевидно и просто, а потому, что appbar не относится к sidebar с какой стати в нем должна быть логика для него?

а я где-то писал, что в appbar должна быть логика открытия сайдбара?

http://knockoutjs.com/examples/gridEditor.html

как здесь

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

Комментарий будущему себе оставь, чтобы потом поведение осталось очевидным)

а я где-то писал, что в appbar должна быть логика открытия сайдбара?

Так ты говоришь, что через эммт и вотчеры лучше

Комментарий будущему себе оставь, чтобы потом поведение осталось очевидным)

Спасибо за советы, завтра ещё помедитирую на эту тему)

Так ты говоришь, что через эммт и вотчеры лучше

Да, на аппбаре. Из аппбара эмитть событие нажатия кнопки

как здесь

Так сделай) на vue очень легко переписывается нокаут, принципы у них схожи

https://twitter.com/vuetifyjs/status/882278671213633536

Да, на аппбаре. Из аппбара эмитть событие нажатия кнопки

хрень

обоснуй

так принято делать, но это неправильно потому что ты все равно логику работы с сайдбаром пихаешь в аппбар, делая в нем эмиты событий которые будут еще и в layout приниматься и оттуда только уже посылаться в sidebar

так принято делать, но это неправильно потому что ты все равно логику работы с сайдбаром пихаешь в аппбар, делая в нем эмиты событий которые будут еще и в layout приниматься и оттуда только уже посылаться в sidebar

Какая логика работы с сайдбаром? Ты просто эмитишь событие, тем самым обозначая естественное поведение компонента.

тогда эмит должен делаться не в layout, а в $root или отдельный инстанс

так принято делать, но это неправильно потому что ты все равно логику работы с сайдбаром пихаешь в аппбар, делая в нем эмиты событий которые будут еще и в layout приниматься и оттуда только уже посылаться в sidebar

ты мне скажи, как ты в аппбаре (или где там?) получаешь ссылку на сайдбар?