Style Guide Collaboration

[chrisvfritz]

I'm developing an official Vue style guide and although not all rules there will be enforceable through this plugin, I think it makes sense to collaborate here, especially for those rules that are enforceable. Right now, I'm thinking the style guide could serve as the official documentation for any recommended rules in this plugin and these two resources could be published together.

You can see the current progress in this branch, with the live result here. Any feedback/contributions are welcome and rules are not set in stone, so don't panic if you see something you disagree with. 😄

I've also not kept up-to-date with the conversation in various issues here, so I apologize if some of it is out of sync with plans you've been making. Please ping me on discussions you think I should know about, or if you'd like my input.

[armano2]

👍 I like it

[mysticatea]

Good idea ❤️
I think good if we have predefined configs about the priority A to D.
Also, the style guide is the best source of rule ideas.

[chrisvfritz]

@mysticatea Agreed, though inspiration can also go both ways. If you have any rules from the plugin that should be added, or if a recommended rule in the plugin conflicts, please discuss it here.

Feedback on the categories I've created are also welcome - as well as feedback on which category each rule belongs in. I tried to put a lot of research and thought into them, but this is still the first community style guide I'm creating and I'm sure there are considerations I'm not experienced enough to foresee.

[chrisvfritz]

@filipalacerda Also tagging you here, as I know you've thought about this quite a lot at Gitlab and your internal style guide was actually a source of inspiration for the official community one. 🙂

[sdras]

This is amazing! I love it.

A couple of notes: (these are so minor)

Complex computed properties
Whenever possible, computed properties should be split into as many named values as possible.

I think this one could do with an example.

Component style scoping
Component styles should be scoped.

Clarification needed: I know a good number of people who won't scope the topmost App.vue component tag, but every subsequent component thereafter, are we deciding that this is an antipattern too? If not, it might be worth detailing this a bit more.

Self-closing components
Components with no content should be self-closing in single-file component or string templates, but never in DOM templates.

Can you please explain the inconsistency here?

This is fantastic, I'm sure it's going to be a great resource for people.

[chrisvfritz]

@sdras Great comments! I just updated those three entries to (hopefully) resolve your concerns. Let me know how I did. 😄

[sdras]

Perfect! Thank you.

[filipalacerda]

💪 Love this!
GitLab style guide goes mainly in the same direction - https://docs.gitlab.com/ce/development/fe_guide/style_guide_js.html.

Can't wait to have a linter to check them instead of doing manually in every merge request!

Some suggestions:

Props Casing

A rule for pros name casing in templates, similar to "Component name casing in templates", it is something we struggle with in our codebase, we often see:

<component myProp="prop"></component>

and

<component my-prop="prop"></component>

We created an entry to use the latter: https://docs.gitlab.com/ce/development/fe_guide/style_guide_js.html#naming

name property casing

We haven't decide on a rule to this one which makes us have components without it, other with it sometimes in camelCase others in PascalCase.
Might be worth adding a rule in priority B or C to aim for consistency

{
  name: 'MyComponent'
}

{
  name: 'myComponent'
}

Let's get this done 💪 I would love to help!

[armano2]

@filipalacerda can you make tickets with new rule proposition and i will work on this tonight (i have no idea how to name them).

[shentao]

When it comes to templates I prefer having the attributes in such order: directives -> attrs -> :attrs -> @events.

Example:

<input 
  v-for="name of names" 
  v-model="name" 
  type="text" 
  :disabled="isDisabled(name)" 
  @change="validate(name)"
/>

Could also order based on the native attributes first and directives/props/events second.

[filipalacerda]

@armano2 created #92 and #93 :)

[chrisvfritz]

@filipalacerda I like both of those ideas. 🙂 I'll also add a rule about max attributes per line and take another look at Gitlab's style guide to see what else you added since I last looked at it.