Rule proposition: order-in-components

[michalsnik]

As I mentioned in #10, I think that creating separate issue for each rule proposition has many benefits, so this is my first proposition:

Rule name: order-in-components
Description: Keep order of properties in components according to https://docs.gitlab.com/ce/development/fe_guide/style_guide_js.html#ordering

Gitlab's style guide lists all properties, I would however consider grouping lifecycle hooks in order to make it simpler, like so:

• name
• props
• mixins
• data
• components
• computedProps
• methods
• lifecycle hooks

Introducing order rule we can make sure that every component is written in exactly the same way, which would make it more readable and consistent across codebase.

This rule should be configurable, so that anyone can amend proposed order in .eslintrc.

[yyx990803]

I personally prefer having all assets at top of the component (like dependencies), and then group all state-related options (props, data, computed), hence:

• name
• assets (mixins, components, directives, filters)
• props
• data
• computed
• methods
• lifecycle hooks
• render (if used)

[michalsnik]

Alright @yyx990803, it makes sense 👍 We can make this order the default one, but we'll also make it possible for devs to change the order in .eslintrc so our recomendation is not the only right choice.

[michalsnik]

I started to work on this, and there are far more properties that we should take into consideration. Order I came up with is as follows:

1. Options / Misc (name, delimiters, functional, model)
2. el
3. Options / Assets (components, directives, filters)
4. Options / Composition (parent, mixins, extends, provide, inject)
5. props
6. propsData
7. data
8. computed
9. methods
10. watch
11. lifecycle hooks
12. template
13. render
14. renderError

What is in braces should be treated equally in terms of order, the rest should be in the exact order.
I kept grouping of some properties (misc, assets and composition) in tact with official documentation, but had to tear DOM properties. I'd like to know your thought on this guys. I'll start implementing it and if we came up with different order we'll simply change the default configuration. If there are any other properties that I should take into consideration let me know!
cc @yyx990803 @chrisvfritz

Another thing is what kind components definitions are we going to support. My first thoughts are:

1. export.default {} in *.vue file
2. Vue.component('xxx', {}) in any file

But sometimes we also assign simple objects directly to a variable and this is our component, but this way we have no chance to recognise if it is actually a vue component, so I think we should rather focus only on those two scenarios I mentioned above. I just want to make sure.

// Update
I found another one: async component, but it might be harder to detect because of different ways of declaring component's body in this case. It certainly would not be enough to find resolve in async component's function..

[yyx990803]

Looks good - tweaked a bit more:

• Options / Misc (name, delimiters, functional, model)
• Options / Assets (components, directives, filters)
• Options / Composition (parent, mixins, extends, provide, inject)
• el / template
• props
• propsData
• data
• computed
• watch
• lifecycle hooks
• methods
• render
• renderError

The main thing is I moved template up alongside el, and moved methods to be after lifecycle hooks.

It's interesting because putting render last is kind of a convention from React land, but I'm much more used to seeing templates earlier to get a visual understanding of a component.

[nirazul]

Just wanted to weigh in that we've created a similar plugin to tackle the same issue. It's in use in our agency so it's sort of battle tested.
Maybe this helps you solve this task faster 🙂

eslint-plugin-export-keys

[michalsnik]

Thanks @nirazul , I did similar rule in eslint-plugin-ember already so it won't be a problem :) I just need to get my head around it, probably tomorrow :)

[michalsnik]

Released as v3.2.0. Rule is disabled by default, that's why it's a minor release. We'll change it to be enabled by default while finishing beta period.