Skip to content

Rule proposal: private-property-names #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
michalsnik opened this issue Nov 26, 2017 · 4 comments
Open

Rule proposal: private-property-names #246

michalsnik opened this issue Nov 26, 2017 · 4 comments

Comments

@michalsnik
Copy link
Member

According to the Style Guide we should warn about following keys:

  • _foo
  • $foo

and encourage to prefix private properties with $_ (e.g. $_foo).

This rule could live alongside no-reserved-keys, but we might as well keep only this rule, to not duplicate warnings.

@chrisvfritz
Copy link
Contributor

I would hold off on this one for a little bit, as I'd like Evan to first approve this convention when he reviews the style guide.

@michalsnik
Copy link
Member Author

@chrisvfritz do we know more now?

@chrisvfritz
Copy link
Contributor

I don't think we've had a definitive ruling yet, but I'll ping @yyx990803. 🙂

@chrisvfritz
Copy link
Contributor

chrisvfritz commented Jul 31, 2018

Still no word from Evan, but let's move forward on this anyway. I think no-reserved-keys can still be useful in conjunction with this, since the $_ is only for private property names, like in plugins. There are probably two scenarios we can catch:

  • Any property names starting with _. In this case, we can warn that for private property names, the $_pluginName_propertyName format should be used to avoid conflicts with Vue's private property names starting with _ and also conflicts with other plugins.
  • Any property names starting with $_, but not following the $_pluginName_propertyName convention. So any property names starting with $_ should match this regex: /^\$_\w+_\w+$/. If it does not match, we can show the same warning about the format.

What do you think @michalsnik?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants