А как изменять объект внутри компонента, если он приходит как

value, а это пропс и его нельзя вешать на v-model контролов?

через computed с сеттером

https://ru.vuejs.org/v2/guide/computed.html#%D0%A1%D0%B5%D1%82%D1%82%D0%B5%D1%80%D1%8B-%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D1%8F%D0%B5%D0%BC%D1%8B%D1%85-%D1%81%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2

хм, интересный подход, спасиб. А это костыль или бестпрактис?

зебест

Имеется в виду мутировать объект или целиком менять? В v-model, наверное, идут поля объекта, а не объект?

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

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

можно поля объекта через prop.sync биндить

Не понял, как это поможет

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

Если он напрямую мутируется, то это скорее аналог мутирования пропса. А в изначальном вопросе требовалось избежать мутации пропса. Мутация объекта, который провайдится - даже хуже мутации объекта. Ну и тут провайд связывает компоненты сильнее. Чуть менее универсально, надо уже на компоненты конкретные смотреть

так нужна как раз, чтоб внутри вложенных менять объект "частями"

Он, наверное, имел в виду, что не нужна реактивность самого провайда, потому что provide сам по себе не реактивен.

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

У вас провайд получается просто "потому что утомительно пропс передавать". При этом он не решил проблему мутации, вы предлагаете мутировать объект, который провайдится. Связаны ли они тесно у Сергея - мы не знаем)

Он пытается решить проблему бурения пропсов через провайд

Но с мутацией объекта

Пусть функцию прокинет для изменения

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

Это уже другое дело)

Но у вас идёт мутация входа компонента. Т.е. one way dataflow нарушается. При этом не между парой компонентов, а между глубокой группы. Это работает, и даже эффективно, но надо понимать, что это плохая практика, противоречащая основному интерфейсу взаимодействия компонентов во Vue

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

Ну вот Артём выше предложил провайдить не только объект, но и сеттер для этого объекта. Это уже решает проблему мутации

можно и так, да

И все эти 7 уровней как-то меняют данные?

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

этот вариант, кстати, тоже не без недостатков - в каждом дочернем компоненте придется делать deep clone объекта, иначе v-model будет мутировать оригинальный объект либо можно заменить v-model на bind + event, но это вообще будет плохо

сеттер может быть не целиком на весь объект

да, но без deep clone тут никак, либо нужно отказываться от v-model

Глубокое клонирование нужно только при сеттере глубокого объекта. Сеттер может не делать этого. Можно иметь много сеттеров, можно сеттеру передавать, что именно менять и тп

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

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

obj = { a: { b: 1 } } без deep clone нельзя заменить obj.a.b так, чтобы это не повлияло на оригинальный объект

Можно

Вы можете мутировать там где передаёте

можно

setObjB(value) { obj.a.b = value } setObjAField(value, key) { obj.a[key] = value } Ну и тд

Влиять на оригинальный объект его владельцу - можно