In vue's official docs I found the usage about $root at the edge cases section. "Edge Cases" makes me feel like using this.$root(or this.$parent) to mutate the data of root instance in a child ponent is not a normal or remended way.

I know vuex is the best state management option for large and plex vue application and it has more advanced features and better for debugging. But that does not convince me the this.$root is not good.

As the docs says when this.$root to mutate root data is not possible to track when and where data changes happen and is not good for debugging. But what I want to know is:

Is this.$root approach only has disadvantages about debugging? Except for debugging related problems, is there any other issue of using this.$root to mutate the root data? If so can anyone give me a small example to showcase that problem because I cannot think out any case to avoid using it (suppose my vue app is not that large and plex). Thanks in advance!

In vue's official docs I found the usage about $root at the edge cases section. "Edge Cases" makes me feel like using this.$root(or this.$parent) to mutate the data of root instance in a child ponent is not a normal or remended way.

I know vuex is the best state management option for large and plex vue application and it has more advanced features and better for debugging. But that does not convince me the this.$root is not good.

As the docs says when this.$root to mutate root data is not possible to track when and where data changes happen and is not good for debugging. But what I want to know is:

Is this.$root approach only has disadvantages about debugging? Except for debugging related problems, is there any other issue of using this.$root to mutate the root data? If so can anyone give me a small example to showcase that problem because I cannot think out any case to avoid using it (suppose my vue app is not that large and plex). Thanks in advance!

• javascript
• vue.js
• vuejs2
• vuex

1 Answer 1

This is all about good and bad architecture. You should always design your code so you share the least data you can (this is not even related to Vue).

Your vue ponent has private and public methods and fields. Consider all the method in ponent to be private. And $emit and props to be public. Accessing private methods and fields are always a bad idea, why?:

• It's not clear who changed the state. If you have something like @click some deep child, you could end up in the whole tree of ponents rerendering because you might wanna change data inside of root.
• How would you unit test your ponent? You will need to attach the root all the time.
• Ok, imagine then that you have a huge enterprise application. And you access $root in multiple places. Now a new developer es and changes the call signature withing one of a ponent but forgets to change it from another one. You will end up in a broken app. How is it different from vuex? In your vuex you should have modules, so there won't be a single place that all ponents access.
• So debugging. Tools like vue-devtools track vuex but not state. Now imagine that some data just magically change in your ponent. And this is because another developer did something like setInterval(() => $root.setDataTime(Current time ${Date.now()}), 1000). You check the changes and there're no mits in the vuex nor on your ponent.