Because oneself is half-way monk (Java turn), so for the front-end code of some specifications are not very understand, are looking at other people’s code is how to write than gourd painting gourd, also do not know why… Vue officially provides some coding rules today. So let’s see how much of the code we write doesn’t follow the specification: the original address

Good programming habits in using VUE:

  • Necessary:

    These rules will help you avoid mistakes, so learn and accept their full cost

  • It is highly recommended

    These rules can improve readability and the development experience in most projects

  • recommended

    When there are multiple equally good options, choosing any one ensures consistency

  • Use caution

    Some VUE features exist to accommodate extreme situations or to help smooth the migration of old code that cannot be overused

  1. Component names are multiple words – necessary

  2. The data of a component must be a function — necessary

    When data is an object, it is shared among all instances of the component

  3. The prop definition in a component should be as detailed as possible, and at least define its type – if necessary

    A detailed prop definition has two benefits:

    • They specify the component’s API, so it’s easy to understand how to use the component
    • In a development environment, if a component is provided with a prop in the wrong format, Vue will issue a warning to help you catch the potential source of the error

  4. Set key values for v-for — necessary

    Otherwise Vue will optimize the rendering to minimize possible DOM changes when updating the DOM with array changes

  5. Avoid using v-if and V-for together — necessary

    V-for has a higher priority than V-IF, so we can filter the data before rendering

  6. Set scope for component styles — necessary

    • scoped
    • CSS Modules
    • BEM

  7. Private property name — necessary

    Vue uses the _ prefix to define its own private property, so using the same prefix runs the risk of overwriting the instance property

  8. Component files — highly recommended

  9. Case of single file component files – highly recommended

    It’s best to always start filenames with uppercase words because they are most friendly to the code editor’s autocompletion

  10. Base component name – highly recommended

    These components include only HTM elements, other base components, and third-party UI component libraries

    The benefits of this are:

    1. Components of the same nature are grouped together for easy identification
    2. Avoid arbitrary prefixes when wrapping simple components
    3. You can put them in a global folder and import them uniformly using tools like Webpack

  11. Singleton component name – strongly recommended

    Components that are used only once on a page and do not accept prop should be named with The prefix The

  12. Tightly coupled component names – highly recommended

    Components that are tightly coupled to a parent should be prefixed with the parent’s name

  13. Word order in components – highly recommended

    The component name should begin with a high-level word and end with a descriptive modifier

    For example SearchButtonClear. Vue SettingsCheckboxLaunchOnStartup. Vue

  14. Self-closing components — highly recommended

    Components that have no content in single-file components, string templates, and JSX should be self-closing

    Write it all in the DOM template

  15. Case of component names in templates – strongly recommended

    Use PascalCase in the single-file component and Kebab-Case in the DOM template

  16. Case of component names in JS/JSX – strongly recommended

    The component name should always be PascalCase

  17. Complete word component name – highly recommended

  18. Case of Prop name — highly recommended

    More natural in JavaScript is camelCase, and more natural in HTML is Kebab-Case

  19. Elements of multiple attributes: write in lines

  20. Simple expressions in templates – highly recommended

    Component templates contain only simple expressions; complex expressions should be refactored to evaluate properties or methods

  21. Simple computing properties – highly recommended

    Divide complex computational properties into as many simpler computational properties as possible

  22. Attribute values with quotes – highly recommended

    Non-empty HTML attribute values should always be enclosed in quotes, such as

  23. Directive abbreviation — highly recommended

  24. Order of component/instance options – recommended

    1. el
    2. name\parent
    3. functional
    4. delimiters\comments
    5. components\directives\filters
    6. extends\mixins
    7. inheriAttrs\model\props(propsData)
    8. data\computed
    9. Watch \ Lifecycle hooks
    10. methods
    11. template(render)\renderError

  25. The order of element attributes – recommended

    1. is
    2. v-for
    3. v-if\v-else-if\v-else\v-show\v-cloak
    4. v-pre\v-once
    5. id
    6. ref\key
    7. v-model
    8. v-on
    9. v-html\v-text

  26. Blank line in component/instance option – recommended

  27. Order of top-level elements of a single – file component – recommended

  28. No key used in v-if/v-else-if/v-else — use with caution

    If the elements are of the same type, it is better to use key

  29. Element selectors in scoped – use with caution

    Element selectors should be avoided in scoped (slow)

  30. Implicit parent – child communication – use with caution

    Use the prop and event to communicate with the parent rather than this.$parent or changing the prop

  31. Non-flux global state management – use with caution

    Global state should be managed through Vuex rather than this.$root or a global event bus

This finally solved my long time doubts, ha ha ha ha later coding to according to the specification, so good for everyone ~ ~ ~