Сергей_Наумов
Друзья, какой самый простой способ сделать общее хранилище для всех компонентов?
Сергей_Наумов
в сторону vuex-а начал смотреть, но мне кажется не совсем то
Nikolay
vuex
Иван
Alex
Друзья, какой самый простой способ сделать общее хранилище для всех компонентов?
пустой экземпляр вью, даже реактивность будет))) можно shared объект сделать
Stanislav
Друзья, какой самый простой способ сделать общее хранилище для всех компонентов?
А зачем тебе хранилище?
Сергей_Наумов
ну чтобы не гонять по элементам (по иерархии) данныче через параметры
Сергей_Наумов
наверное shared-объект наиболее подходящее
Alex
гоняйте по иерархии
Сергей_Наумов
и данные и методы
Egor
Гитпульни демо и сдай
Сергей_Наумов
Есть вероятность, что-то делается не так
структурно это выглядит так:
[ приложение ] -> [Форма] -> [поля формы] -> [вложенное поле (форма в форме)]
Сергей_Наумов
то есть мне нужна рекурсия
Сергей_Наумов
есть форма
Сергей_Наумов
в ней поля
Сергей_Наумов
одно из полей может быть вложенной формой (на уровне СУБД это 1:m)
Сергей_Наумов
вот в этой вложенной форме должны использоваться те же методы, что и в обычной форме
Сергей_Наумов
если их тупо тянуть сверху вниз -- это не красиво
Сергей_Наумов
shared-элемент ведь?
Сергей_Наумов
ну или другой вариант -- дедактирование дерева
Сергей_Наумов
в дереве сколько угодно вложенностей
Сергей_Наумов
это тоже рекурсия
Сергей_Наумов
хотя нет, это плохой пример
Сергей_Наумов
да как-то это выглядит странно
Сергей_Наумов
ладно если у меня один метод
Сергей_Наумов
а когда больше трёх -- начинает напрягать
ℝei
если это выглядит тебе странно это не значит что это неправильно, плохо, etc
Сергей_Наумов
а если 10 методов?
ℝei
vuex
Сергей_Наумов
вот-вот
Sunlive
редакс
ℝei
но это не отменяет того факта что это странно
ℝei
это нормально)
Сергей_Наумов
добавляется новый метод и мне по всей иерархии его размазывать? конечно это плохо
ℝei
если у тебя метод одного компонента используется в другом у тебя проблема в архитектуре
Sunlive
если хочется изврата бери ивент-бас
Сергей_Наумов
если у тебя метод одного компонента используется в другом у тебя проблема в архитектуре
допустим такую ситуацию (я сейчас упрощаю):
Форма содержит 2 компонента:
textarea и input[type=text]
в обоих этих компонентах висят события на @input
и события эти довольно сложные (обработчик регекспов, автозамены и так далее)
компоненты эти в принципе разные
но метод обработки ввода (@input) одинковый
Может быть я что-то не понимаю, но подскажи мне, в чём тут архитектурная проблема?
Сергей_Наумов
общий
Сергей_Наумов
не дублировать же его
Sunlive
вынеси в модуль\сделай миксин
Сергей_Наумов
миксин -- это что?
Sunlive
https://ru.vuejs.org/v2/guide/mixins.html
Сергей_Наумов
спс
Sunlive
короч мержится с твоим обьектом вью при монтировании
Sunlive
в итоге сплитишь 1 код на 2 компонента
Sunlive
единственное над за полями смотреть
Sunlive
и там приоритеты есть
Sunlive
ну вообщем в доке все есть
🍅Ťомат
Бонжур.
Есть v-for из массива объектов, который циклично обновляется. Как отследить изменение поля в одном из объектов массива? Состояние нигде не храню, не умею пока.
Alexander
ed.t
народ, скажите пожалуйста https://github.com/petervmeijgaard/vue-2-boilerplate/tree/master/src/store/modules/auth вот такая организация стора это все еще актуально или есть решения по лучше? (для больших црм-подобных проектов)
Sasha
Да актуально, не обязательно так как показано у чувака в репе, но это уже дело вкуса
Sasha
Если есть желание и время написать свой стор все в ваших руках
ed.t
Да актуально, не обязательно так как показано у чувака в репе, но это уже дело вкуса
спасибо, я пришел из мира react+redux, поэтому лучше начать как у кого-то и потом разобравшись уже допилить)
Андрей
спасибо, я пришел из мира react+redux, поэтому лучше начать как у кого-то и потом разобравшись уже допилить)
Забей пока на стор. Тебе он здесь почти не нужен будет.
ed.t
Забей пока на стор. Тебе он здесь почти не нужен будет.
у меня на повестке дня crm с авторизацией, управления пользователями, роли, статистики и пр
ed.t
в режиме SPA
ed.t
в теории еще с нормализацией данных
ed.t
но это не сразу
Sasha
Для CRM конечно нужен
ed.t
я пока хз что когда тут нужно, просто знакомлюсь)
Anonymous
А ректщики говорят что у них у них Фреймворк лучше и вуе не нужен(
Sasha
А ректщики говорят что у них у них Фреймворк лучше и вуе не нужен(
B в тихаря массово мигрируют на Vue
Alex
Каждому своё
Roman
да мне так же говорили сегодня
Roman
глупый спор
Андрей
B в тихаря массово мигрируют на Vue
А реактщики понимают, что надо смотреть полностью на картину, а не тупо топить за свою технологию)
Stanislav
А реактщики понимают, что надо смотреть полностью на картину, а не тупо топить за свою технологию)
Ну это какие-то избранные
Stanislav
Ну, мне кажется, что все адекватные люди так стараются делать)
Ладно, будем считать, что все адекватные :)