Valid use case of mutating props

[zeodtr]

I encounter the following case frequently and I think it is a valid use case of mutating props.

• There are multiple complex (and heavy) data objects to edit.
• A parent Vue component manages child 'editor' Vue components that edit (= mutate) the data object.
• Parent Vue component has the data objects, but does not know the details of the data object.
• Child Vue component know the details of the data object. So it's the child Vue component's responsibility to mutate the object.
• So, emitting update events by child Vue components for the parent to mutate the object is unreasonable (parent does not know what to do with it).
• And, since the data object is heavy and thus the initializing cost for the child Vue component with the 'new' (mutated) data object prop is high, passing data object prop with v-model fashion is uneasonable.
• Since there are multiple data objects, it is unreasonable to set it to a global datastore. Since parent Vue component exactly knows which data object belongs to which child Vue component, it is far easier and modular to send the data object itself as props, instead of sending some key to search for the global datastore.

In Vue, there are two limited options.

• One is the read-only props (+ emitting events to 'delegate' mutating and receiving 'new' prop as s result).
• The other is the global datastore.

I think there can be a third option:

• mutable props (object type only).

If the maintainability of source code is worried, a prop property 'mutable' can be introduced to mark the case.

Any comment is welcomed.

[edison1105]

sounds like vuejs/rfcs#279

[zeodtr]

Actually, it is somewhat the opposite.
I want to modify the object props, and it should be considered a legitimate way rather than a hack.
And I think that it would be helpful if there is a way to express the intention (to modify the object props) in the source code.

[zeodtr]

Additional idea.

'vue/no-mutating-props' warning from ESLint can be avoided with this code pattern:

function mutateProp(propName: string, func(prop) => void) {
    func(props[propName]);
}
...
mutateProp('anObjectProp', (prop) => prop.abcd = 123);

If this mutateProp is provided by Vue.js framework itself for 'mutable' props, programmers can find the 'hard to maintain' part of the code easily.

[drahkrub]

This eslint warning can also be avoided by using toRef().

However: (quoted from there)

When toRef is used with component props, the usual restrictions around mutating the props still apply. Attempting to assign a new value to the ref is equivalent to trying to modify the prop directly and is not allowed.

I've created a small example in the Vue SFC Playground and I just don't understand what's wrong with it doing it this way.

I experience the case described by @zeodtr in his original post each and every day in our (rather large) vue project - and I handle it as described without any problems so far.

If this is "not allowed", then why is it not prevented in the first place?