eslint-plugin-vue icon indicating copy to clipboard operation
eslint-plugin-vue copied to clipboard

Rule Proposal: vue/no-shared-component-provide

Open onexdata opened this issue 6 years ago • 0 comments

Please describe what the rule should do:

The rule should act identical to "vue/no-shared-component-data" except on the provide object.

According to the Vue official docs (found here) "The provide option should be an object or a function that returns an object.", but this is also the case for the data object; it can be an object or a function that returns an object, however, if it's an object, the component data is shared, which is rarely if ever the desired effect, which is why the "vue/no-shared-component-data" rule was created.

There should be a linting rule that can enforce a function that returns an object in "provide", just like "data", because a provision that is not a function that returns an object has no access to the component's "this" scope, and if the component is instantiated more than once, will share any generated provisions, which is rarely if ever what is intended.

No access to "this" also makes many devs scratch their heads wondering why they get errors on this.$store and other scope issues.

This rule will make it easy to avoid provide/inject debugging, which is why many junior devs return to prop-drilling or vuex in their components, which makes them less reusable, and is probably why the official vue docs state: "provide and inject are primarily provided for advanced plugin / component library use cases. It is NOT recommended to use them in generic application code.", because the docs also state Vue's provide/inject is just like React's "context", and in the official Vue podcast they say "provide/inject was created to avoid prop-drilling and gluing components to vuex", which is also identical to React's context. Also, in many podcasts and talks, React developers longed for provide/inject until react copied it with context.

This rule will help sooth the community and educate developers.

What category should the rule belong to?

  • [ ] Enforces code style
  • [X] Warns about a potential error
  • [ ] Suggests an alternate way of doing something
  • [ ] Other (please specify:)

Provide 2-3 code examples that this rule should warn about:

export default {
  provide: {
    profile: this.$store.this.doesnt.exist
  },
};
export default {
  provide: {
    profile: {
      uhOh: 'This exists but will be shared if this component is reused on the same page, which is probably never intended and could be a planted landmine; users often already expect "profile" to be isolated just like "data" is, but unless it gets the same rule tooling, its not'
    }
  },
};

Additional context

onexdata avatar Feb 14 '19 18:02 onexdata