preface

Since ancient times, Chinese naming culture is extensive and profound, often to take a good name and rack their brains. So what can a good name do?

  1. The connotation of the name must match the inherent nature of the user
  2. Do not share the same name with celebrities, not easy to share the same name, innovative, truly reflect the role of the name to distinguish people
  3. Loud and easy to read fluent and pleasant to listen to, good consonant, because the sound meaning also affects people, people also have a conditional reflex
  4. Easy to write easy to record taboo strokes too numerous rope

The same goes for naming in programs.

  1. A component is named to match its functionality
  2. Do not have the same name as other business components, so that people can distinguish at a glance
  3. It doesn’t have to be cool, but practical. Let developers reflexively see the name and think of the utility scenario of the component
  4. Easy to write and easy to remember, short but concise, not cumbersome

Case of a single file component

Single-file components that either always start with a capital letter (PascalCase) or always start with a -connection (kebab-case) are most complet-friendly to the code editor, because this allows us to reference components as consistently as possible in JS(X) and templates. However, mixing file names can sometimes cause problems with case-insensitive file systems, which is why it is entirely desirable to use the same horizontal line naming.

Base component Naming

Base components (that is, components that show classes, illogical, or stateless) should all start with a specific prefix, such as Base, App, or V.

Counter example * * * * components / | - button. Vue | - loading. Vue | - slide. VueCopy the code
Components are cases of * * * * / | - BaseButton. Vue | - BaseLoading. Vue | - BaseSlide. VueCopy the code

Components of a single active instance

The components of a single active instance should be named with The prefix “The” to indicate their uniqueness. This does not mean that The component can only be used on a single page, but only once per page. These components will never accept any prop because they are customized for your application, not their context in your application. If you find it necessary to add a prop, it shows that it is actually a reusable component that is currently only used once per page.

* * * * components / | - SaleManage counterexample. Vue | - ImportExcel. VueCopy the code
Components are cases of * * * * / | - TheSaleManage. Vue | - TheImportExcel. VueCopy the code

Tightly coupled component name

Child components that are tightly coupled to the parent should be prefixed with the name of the parent. If a component is meaningful only in the context of its parent component, this relationship should show up in the component name, because editors usually organize files alphabetically.

Counter example * * * * components / | - SearchBox. Vue | - SearchItem. Vue | - SearchButton. VueCopy the code
Components are cases of * * * * / | - SearchBox. Vue | - SearchBoxItem. Vue | - SearchBoxButton. VueCopy the code

The order of words that components hit

The component name should begin with a high-level (usually general description) word and end with a descriptive modifier.

* * * * components / | - ClearSearchButton counterexample. Vue | - ExcludeFromSearchInput. Vue | - LaunchOnStartupCheckbox. Vue | - RunSearchButton.vue |- SearchInput.vue |- TermsCheckbox.vueCopy the code
Components are cases of * * * * / | - SearchButtonClear. Vue | - SearchButtonRun. Vue | - SearchInputQuery. Vue | - SearchInputExcludeGlob. Vue  |- SettingsCheckboxTerms.vue |- SettingsCheckboxLaunchOnStartup.vueCopy the code

Full word component name

Autocomplete in the editor is already friendly enough that the cost of writing long component names is minimal and the same efficiency is more understandable. Why not?

* * * * components / | - soManage counterexample. Vue | - woManage. VueCopy the code
Components are cases of * * * * / | - SaleOrderManage. Vue | - WorkOrderManage. VueCopy the code

Case of prop

Always use (camelCase) for declarations, and always use (Kebab-Case) for templates and JSX. Simply follow the conventions of each language. More natural in JavaScript is camelCase. In HTML, it’s kebab-case.

** props: {'greeting-text': String
}
<WelcomeMessage greetingText="hi"/>
Copy the code
** props: {greetingText: String} <WelcomeMessage greeting-text="hi"/>
Copy the code