Потом сабмитить этот новый объект

надеюсь ты меняешь стейт через мутации, экшны?

да

что Вы имеете в виду под новым объктом?
объект всегда один. Есть state.param - пустой, но с набитым кастомным прототипом дефолтных свойств

Нет, но новый синтаксис приветствуется.

new Object или {}
и потом в него добавлять все что нада через this.$set

Компонент где ты сабмиттишь форму

Создай там объект

Вы имеете в виду записывать изменения в отдельный объект?
Но этот стейт используется и в других компонентах... там нужны изменения введённые пользователем тоже... для того и vuex

сейчас попробую накидать песочницу..

Ну в @change пропиши и мутацию для вьюкса

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

Крч ждём песочницу

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

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

Я не чисто вуист, перешел недавно, месяца два назад

https://codesandbox.io/s/admiring-taussig-xx34m

state.setting в main.js - пустой объект с неким прототипом дефолтных значений

component1 - форма на 2 поля, которая в инпутах выводит в value settings.param1 и  settings.param2 соответственно (значения подтягиваются из прототипа, всё ок)

component 2 - рендер значений state.settings на страницу, чтобы видеть их актуальное значение именно в vuex хранилище, а не локальное состояние из компонента1

component 3 - рендер state.settings объекта преобразованного в JSON , чтобы видеть, какие свойства принадлежать именно самому объекту, а не прототипу объекта.

—
Проблема.
Когда в компоненте1 мы делаем меняем значение в одном из инпутов - срабатывает @input событие, которое успешно перезаписывает это свойство внутри объекта settings, делая его явным (попадает в JSON теперь). Но при этом весь изначальный прототип дефолтных свойств стирается  (видно, что пропадает значение соседнего поля, - или можно по в консоли посмотреть, что изначального моего прототипа state.settings больше нет)

А мне нужно чтобы
- и реактивность сохранялась (компонент2 обновлялся)
- и изначальный мой прототип сохранялся (не вытирались дефолтные данные из полей 1 компонента)
- и в итоговый JSON попадал не весь прототип ЦЕЛИКОМ, а только перезаписаенные пользователем данные

Так что возможно мои идеи из «угловатого» не подходят для «прогрессивного «

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

А изначальная цель вообще следующая:
есть скажем 200 настроек у которых есть дефолтные значения. Их нужно отобразить пользователь. Каждый пользователь изменит себе ну от силы 2-5 настроек. А остальные останутся дефолтными. Поэтому и хочу дефолтные хранить в приложении в прототипе объекта, а в бд отправлять только те, что были перезаписаны пользователем, чтобы не отправлять в базу все 200 настроек для каждого пользователя, хотя по сути нужных перезаписано 5.

Может есть какой то другой способ добиться нужного результата проще? без прототипов?

Подскажите, а какие события должны срабатывать, при вызове router.push({ path: /mnemo/${id} }) со страницы /mnemo/... create и mounted - не отловились. А как тогда отлавливать, что изменился параметр?