A. Necessary
- Multiple-word for component’s name
- Data for component must be a function
- The definition of prop should be as detailed as possible (at least specified its type)
- Always use key with v-for
- Never use v-if & v-for to the same element (v-for has a higher priority than v-if when Vue deal with the directives)
- Set the scope for the component style, but use class rather than scoped feature
- Custom private attributes use the $_ prefix
B. Highlycommended
- Separate each component into files
- The filename of a single file component should always be either capitalized or always crosslinked
- The underlying components for which a particular style and convention are applied (that is, components that show classes, Illogical or stateless) should all begin with a specific prefix
- Components that are used only once per page should be named with “the” prefix
- Child components that are tightly coupled with the parent component (that means a component only makes sense in the context of a parent component) should be prefixed with the parent component name.
- Component names should begin with high-level (usually generic) words and end with descriptive modifiers.
- In single file components, string templates and components with no content in JSX should be self-closed-but never do so in DOM templates.
- For most projects, component names should always be PascalCase in single file components and string templates but always kebab-case in DOM templates
- The components name should be PascalCase in JS/JSX, but for applications that define global components only through Vue.component, kebab-case is recommended as an alternative
- Component names should tend to be full words instead of abbreviations
- When declaring prop, it should always be named with camelCase. But in templates & JSX you should use kebab-case
- Seprating multiple properties of an object by multiple rows that can improve the readability of the code
- Component templates should contain only simple expressions, and complex expressions should be refactored into computed properties or methods
- Divide complex computational attributes into as many simpler ones as possible
- Non-empty HTML attribute values should always be quoted
- Instruction abbreviation
C. Recommended
- There should be a uniform order of options for components/instances (default order recommended:https://cn.vuejs.org/v2/style-guide/#%E7%BB%84%E4%BB%B6-%E5%AE%9E%E4%BE%8B%E7%9A%84%E9%80%89%E9%A1%B9%E7%9A%84%E9%A1%BA%E5%BA%8F-%E6%8E%A8%E8%8D%90)
- The properties of elements (including components) should have a uniform order (default order recommended: https://cn.vuejs.org/v2/style-guide/#%E5%85%83%E7%B4%A0%E7%89%B9%E6%80%A7%E7%9A%84%E9%A1%BA%E5%BA%8F-%E6%8E%A8%E8%8D%90)
- Adding blank lines between multiple attributes can improve readability when components begin to be dense or difficult to read
- Single-file components should always keep the script template and style tags in the same order. And style should be at the end, because the other two tags must have at least one.
D. Be Attention (to use these as follow)
- Use v-if/v-else-if/v-else without using key
- A large number of element selectors appear in scoped
- Hidden parent-child component communication (use this.$parent or modify prop)
- Global State Management without Flux (manage global state by using this.$root or a global event bus)
All these referred to https://cn.vuejs.org/v2/style-guide/