тогда computed напиши

тогда computed напиши

вот я тоже об этом думаю... но что то помешало.. счас скажу что..

буду пробовать с computed короче...

Если я после миксина добавлю новый атрибут в дату, оно мне всю дату перезапишет или просто до текущей добавит етот атрибут?

Если я после миксина добавлю новый атрибут в дату, оно мне всю дату перезапишет или просто до текущей добавит етот атрибут?

https://ru.vuejs.org/v2/guide/mixins.html#%D0%A1%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D0%B5-%D0%BE%D0%BF%D1%86%D0%B8%D0%B9

тогда computed напиши

написал работало.. Но мне показалось не очень красивым привязывать v-model к computed который связан со state. Хотя бы потому что мне не нужно что бы компутед этот как то реагировал на v-model и изменения формы.. там у меня свой обработчик..

В общем сделал так.

created тогда копируй свой конфиг в дату

я в data прямо и копирую конфиг или из state если нужно

работает..

но может плохая практика?

created тогда копируй свой конфиг в дату

вроде тоже самое что mounted... те клиентская штука?

created срабатывает до рендера компонента

А data: function() ?

ну тоже

не могу сказать, я за полтора года никогда не делал так. Я не делал data() жирной

ну тоже

в чем разница?

не могу сказать, я за полтора года никогда не делал так. Я не делал data() жирной

понятно... ну можно определение дефолтного конфига вынести из data

но понял что в created тот же эффект просто красивее?

честно скажу не знаю, у меня всегда data() была прострая, а операции со стором я делал через computed или в хуках

но понял что в created тот же эффект просто красивее?

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

и если ты собираешься потом редактировать этот конфиг, то делай копирование объекта

в общем я за полтора года ни разу не держал логику какую-либо в data() и сказать плохо это или нет, не могу, потому, что это просто один из подходов.

вот так лучше?

и если ты собираешься потом редактировать этот конфиг, то делай копирование объекта

он редактируется так: юзер меняет форму которая привязана к нему через v-model .. ну на форму обработчики change и в них запрос к бекунду и сохранения конфига и там и в state

но это все очевидно уже не имеет отношения к created

почему ты это в экшен не вынесешь?

и зачем хранишь вообще defaultConfig именно в компоненте?

точно вот

в action можно... но это просто не будет повторно использоваться и я тороплюсь..

и зачем хранишь вообще defaultConfig именно в компоненте?

ну так дали код там уже кое что было... а куда бы его..

в какой то json конфиг итп...

и опять же, ты мутируешь стейт вне мутаций. ты сделал в хуке this.currentConfig = store.config а потом этот же конфиг коммитишь, хотя по сути ты все это время изменял тот же самый конфиг из стора.

и опять же, ты мутируешь стейт вне мутаций. ты сделал в хуке this.currentConfig = store.config а потом этот же конфиг коммитишь, хотя по сути ты все это время изменял тот же самый конфиг из стора.

это так.. но я еще хочу мутировать конфиг при успешном запросе к беку именно..

хотя строго говоря это и не обязательно

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

но к беку обращаться и менять линк придеться все равно по тз

я тебе просто говорю, что ты не должен так делать, копируй конфиг из геттера, потому, что если у тебя strict: true в vuex стоит, то должно куча ошибок падать при редактировании

Предлагаешь computed и сеттер.. я пробовал так.. setter в этом случае почему то не реагирует на изменения select box

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

нет я предлагал this.config = copy(this.$store.getter.config)

я тебе просто говорю, что ты не должен так делать, копируй конфиг из геттера, потому, что если у тебя strict: true в vuex стоит, то должно куча ошибок падать при редактировании

где копировать конфиг из getter?

нет я предлагал this.config = copy(this.$store.getter.config)

вместо простого присваивания?

в created?

ну да, ты же потом этот конфиг редактируешь

ты имеешь ввиду что присваивание по ссылке.. и оно отражаеться на vuex?

да

Ох бля

сейчас проверю..

у них ссылки все это время одинаковые

у них ссылки все это время одинаковые

неа

state_config: function() { return this.$store.getters["configure/config"] },

создал для проверки просто ссылку на state

ничего там не отражается в state

у тебя vuex strict: true?

у тебя vuex strict: true?

нет

а лучше сделать?

поставь

но типо только для дев режима

strict: process.env.NODE_ENV !== 'production'

ERROR: S client not available

так?

все тоже самое ошибок нет. ничего в state по ссылке не отражается при изменениях

в общем я за полтора года ни разу не держал логику какую-либо в data() и сказать плохо это или нет, не могу, потому, что это просто один из подходов.

Я думаю если логика инициализации синхронная чистая (без побочных эффектов) то её можно выполнять внутри data. Но эту логику стоит вынести в отдельный метод, чтобы data мог оставаться таким манифестом о переменных данных.

Я думаю если логика инициализации синхронная чистая (без побочных эффектов) то её можно выполнять внутри data. Но эту логику стоит вынести в отдельный метод, чтобы data мог оставаться таким манифестом о переменных данных.

я в created уже перенес

Я думаю если логика инициализации синхронная чистая (без побочных эффектов) то её можно выполнять внутри data. Но эту логику стоит вынести в отдельный метод, чтобы data мог оставаться таким манифестом о переменных данных.

согласен, я просто не рассматривал такой подход. И не знаю есть с ним какие-то проблемы

все тоже самое ошибок нет. ничего в state по ссылке не отражается при изменениях

ну должно в консоль падать куча ошибок

конечно еще надо default config перенести куда то наверное в отдельный файл и импортировать..

ну должно в консоль падать куча ошибок

ничего нет такого

А почему DEFAULT_CONFIG не сделать константой?

так он и так const..

или как его объвить и где?

мне кажеться в файлике просто..

Или прямо над export default или в другом файле

я бы default конфиг превратил бы в фабрику

Ну под константой я подразумеваю глобальную неизменяемую переменную (а не const)

я бы default конфиг превратил бы в фабрику

что бы отдавать или его или конфиг из state?

Ну под константой я подразумеваю глобальную неизменяемую переменную (а не const)

типа DEFINE как в пыхе..

что бы отдавать или его или конфиг из state?

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

this.config = defaultConfig();

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

только конфиг? без условия if state?

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

+++

только конфиг? без условия if state?

нет, это уже другая логика

Да, фабрика лучшее решение, согласен!

Только не внутри обьекта компонента. Можно прямо над export default или в отдельном файле

ага

Только не внутри обьекта компонента. Можно прямо над export default или в отдельном файле

в отдельном мне лучше..

там еще один файл с массивами серверов... и от него зависит и конфиг и сам калькулятор..

видимо все эти данные лучше в отдельные файл

и затем export default объект всего что нужно калькулятору..

ну все конфиги эти в один файлик объединить..

ничего нет такого

https://codesandbox.io/s/64qx0m6413