или методы

Вторая подобная проблема за сегодня когда опечатка в названии перменной/метода Надо бы чтобы народ поделился как грамотно линтеры настраивать чтобы ловило и подсвечивало в рабочих средах...

Я использую typescript + vscode

Остальное игрушки)

?

юзеры всех ангуляров кроме последних не люди вообще. там версии либ не синкаются, юзается допотопный вебпак. какието внутренние МЕТАДАТЫ, господи

*перекрестился в испуге*

всё что меньше лейтест это легаси без поддержки. как ктото может обьявить у нас залочен ангуляр2 я не понимаю

я просто в своё время думал есть какието форки ангуляров и там худо бедно комьюнити поддеживает. ничерта подобного. оно всё держится на лоченых либах десятки релизов назад с кучей глюков. вот четёртый ангуляр. ng2-trim-directive не нравится "метадата". метадата это какаято инфа которую добавляет компилятор!!! ангуляр в пакеты. на 2.2.1 она 4 а на 2.0.0 она три. в интернете конечно нет никакой инфы

ну вот последнее Error: No module factory available for dependency type: ContextElementDependency @ Received this error today after upgrading to CLI 1.0.0 (and Angular 4.0.0). Putting Webpack at ~2.2.0 fixed it for me. @ не помогает

Никогда не понимал людей, которые юзают либу, создатели которой её не юзают.

Реакт хотя бы местная внутрекорпоративная поделка авторов мегавелосипеда с четырьмя педалями -- haxe с пхп.

Никогда не понимал людей, которые юзают либу, создатели которой её не юзают.

Так и про вью сказать можно ?

Так и про вью сказать можно ?

Вью как раз первый, кто удачно отрефакторил всю чушь)

да это уже какой то анализ причин

я стараюсь просто описательно как то повествовать

народ, очень нужно ваше авторитетное мнение, подскажите правильный паттерн для такой ситуации: 1) Имеем множество компонентов типа “User”, “Product” и прочее, у них у всех есть свои локальные данные типа “Name”, “Phone”, “Price” и т.д, получаемые по API 2) Эти компоненты имеют “детей”, которые должны иметь возможность менять как-то эти данные для родителя, например, компонент “ProductInfo”, который имеет большую форму на 20 полей, данные которой должны соответствовать данным родителя и быть изменяемыми. 3) Сделать так, чтобы поля формы “ProductInfo” были подвязаны на props родителя - так себе вариант: - v-model не поюзаешь, пропсы мутировать нельзя - на каждое изменение некоторого поля надо эмитить ивент родителю?… 4) Сделать через computed setter: даже не представляю как, ведь данные хранятся в родителе, в пропсах, их мутировать нельзя в любом случае. Vuex тоже тут так себе помощник, this.state.user_name = … делать нельзя, а писать какие-то хитровыдуманные мутации “на все случаи жизни” тоже как-то некрасиво получается 5) Остается один вариант: при маунте (или когда мне нужно) дочернего компонента ProductInfo СКОПИРОВАТЬ данные полученные в пропсах от родители Product в локальные, мутируемые данные, далее делать с ними что хочешь, редактировать, дергать урлы АПИ, и прочее, и может только потом (при успешном сохраненнии) сообщать родителю актуальные данные (или просить его рефрешнуться) Правильный ли это подход (№5)? Есть ли какие-то более чистые альтернативы? Напоминаю, цель - удобная работа с формами на много полей…

народ, очень нужно ваше авторитетное мнение, подскажите правильный паттерн для такой ситуации: 1) Имеем множество компонентов типа “User”, “Product” и прочее, у них у всех есть свои локальные данные типа “Name”, “Phone”, “Price” и т.д, получаемые по API 2) Эти компоненты имеют “детей”, которые должны иметь возможность менять как-то эти данные для родителя, например, компонент “ProductInfo”, который имеет большую форму на 20 полей, данные которой должны соответствовать данным родителя и быть изменяемыми. 3) Сделать так, чтобы поля формы “ProductInfo” были подвязаны на props родителя - так себе вариант: - v-model не поюзаешь, пропсы мутировать нельзя - на каждое изменение некоторого поля надо эмитить ивент родителю?… 4) Сделать через computed setter: даже не представляю как, ведь данные хранятся в родителе, в пропсах, их мутировать нельзя в любом случае. Vuex тоже тут так себе помощник, this.state.user_name = … делать нельзя, а писать какие-то хитровыдуманные мутации “на все случаи жизни” тоже как-то некрасиво получается 5) Остается один вариант: при маунте (или когда мне нужно) дочернего компонента ProductInfo СКОПИРОВАТЬ данные полученные в пропсах от родители Product в локальные, мутируемые данные, далее делать с ними что хочешь, редактировать, дергать урлы АПИ, и прочее, и может только потом (при успешном сохраненнии) сообщать родителю актуальные данные (или просить его рефрешнуться) Правильный ли это подход (№5)? Есть ли какие-то более чистые альтернативы? Напоминаю, цель - удобная работа с формами на много полей…

в-модель поюзаешь. и это точно то же самое что эмитить родиелю, и это правильно.

см. доки по нему внимательно

Я пишу на Ангуляре и немного в шоке от вышесказанного (много) Крайне неразумно делать такие выводы, исходя из статей или как-то либ (кстати что за либы?)

но как можно подвязать v-model дочернего компонента на пропс? разве это не то же самое, что мутировать пропсы?

народ, очень нужно ваше авторитетное мнение, подскажите правильный паттерн для такой ситуации: 1) Имеем множество компонентов типа “User”, “Product” и прочее, у них у всех есть свои локальные данные типа “Name”, “Phone”, “Price” и т.д, получаемые по API 2) Эти компоненты имеют “детей”, которые должны иметь возможность менять как-то эти данные для родителя, например, компонент “ProductInfo”, который имеет большую форму на 20 полей, данные которой должны соответствовать данным родителя и быть изменяемыми. 3) Сделать так, чтобы поля формы “ProductInfo” были подвязаны на props родителя - так себе вариант: - v-model не поюзаешь, пропсы мутировать нельзя - на каждое изменение некоторого поля надо эмитить ивент родителю?… 4) Сделать через computed setter: даже не представляю как, ведь данные хранятся в родителе, в пропсах, их мутировать нельзя в любом случае. Vuex тоже тут так себе помощник, this.state.user_name = … делать нельзя, а писать какие-то хитровыдуманные мутации “на все случаи жизни” тоже как-то некрасиво получается 5) Остается один вариант: при маунте (или когда мне нужно) дочернего компонента ProductInfo СКОПИРОВАТЬ данные полученные в пропсах от родители Product в локальные, мутируемые данные, далее делать с ними что хочешь, редактировать, дергать урлы АПИ, и прочее, и может только потом (при успешном сохраненнии) сообщать родителю актуальные данные (или просить его рефрешнуться) Правильный ли это подход (№5)? Есть ли какие-то более чистые альтернативы? Напоминаю, цель - удобная работа с формами на много полей…

Так? <product> <product-info> <field> <field>

да

да

Данные запрашиваешь в <product> и спускаешь по просам вниз?

но как можно подвязать v-model дочернего компонента на пропс? разве это не то же самое, что мутировать пропсы?

пропсы вниз, эвенты вверх.

пропсы вниз, эвенты вверх.

ивент на изменение каждого каждого инпута?

в дочернем компоненте?

ивент на изменение каждого каждого инпута?

точно так.

ага

и менять уже данные исходя из информации в ивенте.

Идея 1в1 как с обычным хтмл и ванилажс

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

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

Я так и не понял, какой у тебя data flow

Product ({name: ‘Ololo’, price: 120}) ProductInfo (props: [name, price])

2000 members ?

допустим, я хочу это сделать как говорит @houd1n1 <ProductInfo> <input type=“text” name=“description” v-on:input=“emitInputChange(event.target.value, ‘description’)”> </ProductInfo> где обработчик делает примерно следующее: emitInputChange(newValue, fieldName) { this.$emit(‘inputValueChange’, {field: fieldName, value: newValue}); } тогда родитель может одинаково обработать изменения каждого инпута и сам поменять значения в своих локальных данных? <Product> <ProductInfo v-on:inputValueChange=“handleChange” / > </Product> так это задумано?

Ровно так и задуман концепт one day data fllow

хорошо, но а что если пользователь поколбасил поля, а потом передумал их сохранять и хотел бы “сбросить” все это? Придется вызывать рефетч данных компонента Product?

Либо компонент-родитель Product для таких целей должен был бы хранить копию своих же данных на случай необходимости “сбросить” их? Ну, интересуюсь просто как это “принято” делать

Либо компонент-родитель Product для таких целей должен был бы хранить копию своих же данных на случай необходимости “сбросить” их? Ну, интересуюсь просто как это “принято” делать

И так и так можно.

Главное, как можно более явно

чтобы понятно было

да хрен его знает, там измнеений не так уж и много

Зато наконец файлы тестов, лежащие рядом с компонентами в бандл попадать не будут!)

Зато наконец файлы тестов, лежащие рядом с компонентами в бандл попадать не будут!)

Это да ?

2 куска) Поздравляю)

Желаю всем что бы зарплаты росли так же как численность в этой группе.

отвернулся, а у вьютифай русская дока появилась

Для этого надо двигать наше дело как ФИшер двигал шахматы)

чет библиотечка прям на глазах хорошеет

отвернулся, а у вьютифай русская дока появилась

почаще отворачивайся

надеюсь что станет популярной как елемент уи

почаще отворачивайся

?

хм, а с подчиненными сработает?

надеюсь что станет популярной как елемент уи

И - индукция

отвернулся, а у вьютифай русская дока появилась

Линк можно, пожалуйста)

https://next.vuetifyjs.com

Сенк

Больше всего бомбит от того что vuetify не юзает свои префиксы для стилей. Постоянно конфликтует со стилями приложения.

А разве scope стили не будут решать эту проблему? ты же про наименования классов?

народ, очень нужно ваше авторитетное мнение, подскажите правильный паттерн для такой ситуации: 1) Имеем множество компонентов типа “User”, “Product” и прочее, у них у всех есть свои локальные данные типа “Name”, “Phone”, “Price” и т.д, получаемые по API 2) Эти компоненты имеют “детей”, которые должны иметь возможность менять как-то эти данные для родителя, например, компонент “ProductInfo”, который имеет большую форму на 20 полей, данные которой должны соответствовать данным родителя и быть изменяемыми. 3) Сделать так, чтобы поля формы “ProductInfo” были подвязаны на props родителя - так себе вариант: - v-model не поюзаешь, пропсы мутировать нельзя - на каждое изменение некоторого поля надо эмитить ивент родителю?… 4) Сделать через computed setter: даже не представляю как, ведь данные хранятся в родителе, в пропсах, их мутировать нельзя в любом случае. Vuex тоже тут так себе помощник, this.state.user_name = … делать нельзя, а писать какие-то хитровыдуманные мутации “на все случаи жизни” тоже как-то некрасиво получается 5) Остается один вариант: при маунте (или когда мне нужно) дочернего компонента ProductInfo СКОПИРОВАТЬ данные полученные в пропсах от родители Product в локальные, мутируемые данные, далее делать с ними что хочешь, редактировать, дергать урлы АПИ, и прочее, и может только потом (при успешном сохраненнии) сообщать родителю актуальные данные (или просить его рефрешнуться) Правильный ли это подход (№5)? Есть ли какие-то более чистые альтернативы? Напоминаю, цель - удобная работа с формами на много полей…

Можно сделать :prop.sync

ребзя, а как мне из вью влиять на набор стилей тега body? инитить корневой компонент с него нельзя же

допустим, я хочу это сделать как говорит @houd1n1 <ProductInfo> <input type=“text” name=“description” v-on:input=“emitInputChange(event.target.value, ‘description’)”> </ProductInfo> где обработчик делает примерно следующее: emitInputChange(newValue, fieldName) { this.$emit(‘inputValueChange’, {field: fieldName, value: newValue}); } тогда родитель может одинаково обработать изменения каждого инпута и сам поменять значения в своих локальных данных? <Product> <ProductInfo v-on:inputValueChange=“handleChange” / > </Product> так это задумано?

Просто используйте в чайлдах пропсы как v-model. Это не возбраняется. Хотя и не хорошо с точки зрения архитектуры

то есть тупо повесить на него шото вроде :class="cond?'class_when_true':''" нельзя

то есть тупо повесить на него шото вроде :class="cond?'class_when_true':''" нельзя

Можно. Но нельзя

можно, но не будет работать

https://www.youtube.com/watch?v=gsffg5xxFQI - Clojure в JS

А вот VueJS в ClojureScript https://github.com/Gonzih/glue

можно, но не будет работать

Будет. Если рендерить бади)))

А вот VueJS в ClojureScript https://github.com/Gonzih/glue

Наркоманы.

так вуй посылает наюух если крепить корневой компонент в бади

так вуй посылает наюух если крепить корневой компонент в бади

Да?)) Не пробовал

А вот VueJS в ClojureScript https://github.com/Gonzih/glue

*Starred

так вуй посылает наюух если крепить корневой компонент в бади

* document.body

так вуй посылает наюух если крепить корневой компонент в бади

А если сделать корневой компонент единственным в боди <body> <div id="app"></div> </body>

А если сделать корневой компонент единственным в боди <body> <div id="app"></div> </body>

и что? директивы вуя в таком случае на бади не распространяются

судя по всему @c01nd01r прав

судя по всему @c01nd01r прав

Никак ты из vue не повлияешь на body

и что? директивы вуя в таком случае на бади не распространяются

Перенеси стили body в корневой компонент, а боди будет просто как wrapper

Кто-нибудь билдер реализовывал для Vue компонентов?

Добрый вечер) вьюшки)

2к найс )

Кто-нибудь билдер реализовывал для Vue компонентов?

шо такое билдер?

Кто знает хорошие курсы по vue 2?

блед

bode builder

Захотел изучить. js знаю так в среднем) базовый

Захотел изучить. js знаю так в среднем) базовый

учи до адванса

потом в доки просто ныряй от вью

профит

Мм..

?

Либо компонент-родитель Product для таких целей должен был бы хранить копию своих же данных на случай необходимости “сбросить” их? Ну, интересуюсь просто как это “принято” делать

Имхо при таких вещах через ивенты или v-model уже не вариант в виду большого количества полей дочерней формы и потому что это лишняя нагрузка, которой можно избежать, я бы рекомендовал юзать екшены, данные родителя хранить в сторе, при, как ты говоришь, колбасе пользователем дочерней компоненты, поосто валидировать, если всё ок и пользователь не передумал, тогда 1 раз вызываешь екшен с пейлодом, экшн меняет даныые через мутации в сторе вот и всё

И данные будут реактивно сменены в паренте

Т.е. проблемы то по сути и нет, схема типичная как в мануалах vuex

Еее, vuex!

Ну а чё? )) по-моему сильно заморочился человек, ну сложная композиция, ну есть паренты и чайлды, в которых чё-то делается и надо наверх