Vue: Incorrectly getting 'Avoid mutating a prop' on a data variable

[sgehrman]

I do have a prop named that in another component inside this vue object and in the parent vue I have that same name, maybe it's getting confused. check it out

[simplesmiler]

Hello!

Thanks for reporting the issue. Please follow the Issue Reporting Guidelines and provide a minimal JSFiddle or JSBin demonstrating the issue.

[sgehrman]

The data vars are in a mixin, maybe that's confusing it.

[yyx990803]

A reproduction means code that can actually run and demonstrate what you are encountering.

[sgehrman]

Yeah, i know, but this is an electron app, and this particular combo of component, mixin, parent is a bit of a pain to setup. If I added you to my github for this project would it be easier for you to get that and run it?

[yyx990803]

No, please try to isolate the problem into a minimal reproduction, because otherwise it could simply be mistakes in your code rather than a bug in Vue.

[yyx990803]

Closing due to inactivity. Please open a new issue with a reference to this one if you can follow up with more information.

[sgehrman]

I tried to reproduce it in jsfiddle, but was unable to. But I assure you it's happening in my Electron app in one case. If you would like to download my code, I can add you to my github.

[znck]

@sgehrman You can create a minimal reproduction repository (with electron). With reproduction steps in README.md

[posva]

Looking at the error, it shouldn't need electron. @sgehrman If you were unable to reproduce it in an isolated way, it's probably something within your code

[lukepur]

I ran into a similar issue to @sgehrman - specifically, receiving the warning:

[Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "<propName>"

despite knowing for sure that the component in question was not mutating the property.

I'm adding here what the issue I experienced was in case anyone stumbles onto this page with a similar problem (as I did). It may or may not be the same root cause as the OP's issue (I'm not using electron for example).

Solution

In my project, I'm creating a component to publish to npm. I've added a subdirectory docs to host a demo of the component on GitHub pages, and that directory was a subproject scaffolded with vue-cli. I believe this setup somehow resulted in 2 separate Vue instances referred to with webpack (one from the component's node_modules in the project root and the other from docs/node_modules).

To fix this, in the docs subproject instead of installing vue as a dependency, alias vue to the root component's node_modules. E.g. (in build/webpack.base.conf.js as generated by vue-cli's webpack template)

module.exports = {
  ...,
  resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
      'vue': resolve('../node_modules/vue/dist/vue.esm.js'),
      ...
    }
  },
  ...
}

Although this solution is specific to a nested vue-cli scaffolded project, the general idea might apply more widely (perhaps to electron?), i.e. that nested vue installations in webpack (and probably other bundlers like browserify) should be avoided and replaced with an alias to a single vue.

Suspected underlying cause

While investigating the problem, at the point that the prop mutation was detected, the observerState.isSettingProps flag was true at the point updateChildComponent() was called, but false when the customSetter() checks for prop mutation.

Inspecting the call stack in Chrome's devtools revealed that 2 separate vue.esm.js sources were being used, hence the inconsistent observerState

So the issue was not with vue but rather a sloppy setup. Hopefully this helps someone else!

Also, thanks @yyx990803 and team for all your hard work in developing what is easily the best FE framework ever 😄