no-mutating-props seems too strict

[leosdad]

What rule do you want to change?

no-mutating-props

Does this change cause the rule to produce more or fewer warnings?

Fewer

How will the change be implemented? (New option, new default behavior, etc.)?

A new option would suffice, but maybe the default behavior should also be changed as well.

Please provide some example code that this change will affect:

<script>
props: {
  localData: { type: Object, required: true },
},
created()
{
  if(!this.localData.screens) {
    this.localData.screens = {};
  }
}
</script>

What does the rule currently do for this code?

It flags it as an error, and I have to disable it globally or locally.

What will the rule do after it's changed?

This should be allowed because the property is an object. I'm not mutating this.localData itself, but another object inside it.

Additional context

[ota-meshi]

Thank you for posting this issue.

Changing the state of a parent component passed by reference on a child component can be confusing.
I recommend that you use an event to communicate from a child to a parent.
https://vuejs.org/v2/style-guide/index.html#Implicit-parent-child-communication-use-with-caution

I don't want to change this rule because I think it should be strict.
You are free to turn this rule off in your configuration.

Thank you for your understanding.

[pimlie]

@ota-meshi Sorry for the duplicate issue, seems like Github search returns different results for vue/no-mutating-props when searching the whole repo and when searching just issues (which I did)

Could we maybe toggle this strict behaviour with a rule option? Priority D / Use with caution doesnt mean its plain wrong and I would love to be able to still make sure that I didn't really overwrite a prop somewhere.

[decademoon]

Is there any way to disallow v-model="value" (where value is a prop) but still allow v-model="value.foo"? It seems now I have to disable the rule completely and I miss out on v-model="value" cases.

[hl037]

Changing the state of a parent component passed by reference on a child component can be confusing. I recommend that you use an event to communicate from a child to a parent. https://vuejs.org/v2/style-guide/index.html#Implicit-parent-child-communication-use-with-caution

I don't want to change this rule because I think it should be strict. You are free to turn this rule off in your configuration.

Thank you for your understanding.

I think it is wrong to say this. Using events forces working on copies of the object. Even though it's the safest way to ensure no coupling between components, and is the best for simple values, it's definitively an anti-pattern for complex objects that needs to delegate the handling of an entire sub-structure to a sub-component (and that don't necessary couple the component, one should just document the property's properties are read/write).
In this case, using event is inefficient and lead to over complicated implementations.
Some times, you just want to break a big component on sub components, and in this case, passing the sub-object to the sub-component and modifying the props of this sub-object is just the best way to do it, and the one that should be recommended. Specially when there are deep nested sub-components.

Vue has a GREAT reactivity system... why not letting it do the job ?

However, I agree with the original purpose of rule that the prop value itself should not be reassigned ( = forbidding props.val = [...]) since it's deprecated and may impact how vue handles the components... and this is why disabling this rule completely should not be the answer...