1. Estándares de codificación necesarios
1.1 Nombre del componente con varias palabras
[Obligatorio] Los nombres de los componentes siempre deben tener varias palabras, excepto la aplicación del componente raíz y los componentes integrados de Vue como .
Ejemplo:
/* good */
Vue.component('todo-item', {
// ...
})
/* bad */
Vue.component('todo', {
// ...
})
1.2 Los datos del componente deben ser una función.
[Obligatorio] Cuando se utiliza una propiedad de datos en un componente (en cualquier lugar excepto en el nuevo Vue), su valor debe ser una función que devuelva un objeto.
Ejemplo:
/* good */
Vue.component('some-comp', {
data: function () {
return {
foo: 'bar'
}
}
})
/* bad */
Vue.component('some-comp', {
data: {
foo: 'bar'
}
})
1.3. La definición de utilería debe ser lo más detallada posible.
[Obligatorio] En el código que envíes, la definición de prop debe ser lo más detallada posible, especificando al menos su tipo.
Ejemplo:
/* good */
props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}
/* bad */
props: ['status']
1.4 Usando clave con v-for
[Obligatorio] Siempre se debe utilizar una clave con un v-for en un componente para mantener el estado del componente interno y sus subárboles. Incluso mantener un comportamiento predecible en los elementos, como la constancia de los objetos en las animaciones, es una buena práctica.
Ejemplo:
/* good */
<ul>
<li
v-for="todo in todos"
:key="todo.id"
>
{
{ todo.text }}
</li>
</ul>}
/* bad */
<ul>
<li v-for="todo in todos">
{
{ todo.text }}
</li>
</ul>
1.5 Evite usar v-if y v-for juntos
[Obligatorio] Nunca utilices v-if y v-for en el mismo elemento.
Generalmente tendemos a hacer esto en dos situaciones comunes:
Para filtrar elementos en una lista (como v-for="usuario en usuarios" v-if="user.isActive"). En este caso, reemplace usuarios con una propiedad calculada como activeUsers que devuelve la lista filtrada.
Para evitar representar listas que deberían estar ocultas (por ejemplo, v-for="usuario en usuarios" v-if="shouldShowUsers"). En este caso, mueva v-if al elemento contenedor (por ejemplo, ul, ol).
Ejemplo:
/* good */
<ul>
<li
v-for="user in activeUsers"
:key="user.id"
>
{
{ user.name }}
</li>
</ul>
/* bad */
<ul>
<li
v-for="user in users"
v-if="user.isActive"
:key="user.id"
>
{
{ user.name }}
</li>
</ul>
1.6 Estilos de componentes de alcance
[Obligatorio] Los estilos en el componente de aplicación de nivel superior y los componentes de diseño pueden ser globales para la aplicación, pero todos los demás componentes deben tener un alcance.
Ejemplo:
/* good */
<style scoped>
.button {
border: none;
border-radius: 2px;
}
.button-close {
background-color: red;
}
</style>
/* bad */
<style>
.btn-close {
background-color: red;
}
</style>
1.7. Nombres de propiedad privada
[Obligatorio] Utilice el alcance del módulo para mantener privadas las funciones a las que no se puede acceder desde fuera. Si esto no es posible, utilice siempre el prefijo $_ para complementos, mixins, etc. propiedades privadas personalizadas que no se consideran API públicas externas. Y viene con un espacio de nombres para evitar conflictos con otros autores (como $ yourPluginName ).
Ejemplo:
/* good */
var myGreatMixin = {
// ...
methods: {
$_myGreatMixin_update: function () {
// ...
}
}
/* bad */
var myGreatMixin = {
// ...
methods: {
update: function () {
// ...
}
}
2. Se recomienda encarecidamente utilizar la especificación.
2.1 Archivos componentes
[Consejo] Siempre que tenga un sistema de compilación capaz de unir archivos, separe cada componente en archivos.
Ejemplo:
/* good */
components/
|- TodoList.js
|- TodoItem.js
2.2 Nombre del archivo del componente de archivo único
[Consejo] El nombre de archivo de un componente de un solo archivo siempre debe comenzar con una palabra en mayúscula (PascalCase).
Ejemplo:
/* good */
components/
|- MyComponent.vue
/* bad */
components/
|- myComponent.vue
2.3 Nombre del archivo del componente básico
[Consejo] Los componentes base (es decir, componentes de presentación, sin lógica o sin estado) que aplican estilos y convenciones específicos deben comenzar con un prefijo específico, como Base, App o V.
Ejemplo:
/* good */
components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue
/* bad */
components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue
2.4 Nombre del archivo del componente Singleton
[Consejo] Los componentes que solo deben tener una única instancia activa deben nombrarse con el prefijo The para indicar su singularidad.
Esto no significa que el componente sólo se pueda utilizar en una sola página, sino sólo una vez por página. Estos componentes nunca aceptan ningún accesorio porque son personalizados para su aplicación, no su contexto dentro de su aplicación. Si considera necesario agregar accesorios, significa que en realidad se trata de un componente reutilizable que actualmente solo se usa una vez por página.
Ejemplo:
/* good */
components/
|- TheHeading.vue
|- TheSidebar.vue
/* bad */
components/
|- Heading.vue
|- MySidebar.vue
2.5 Nombres de archivos de componentes estrechamente acoplados
[Consejos] Los subcomponentes que están estrechamente acoplados con el componente principal deben denominarse con el nombre del componente principal como prefijo.
Si un componente sólo tiene significado en el contexto de un componente principal, esta relación debe reflejarse en su nombre. Dado que los editores suelen organizar los archivos alfabéticamente, esto mantiene juntos los archivos relacionados.
Ejemplo:
/* good */
components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue
/* bad */
components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue
2.6 Orden de las palabras en los nombres de los componentes
[Sugerencia] Los nombres de los componentes deben comenzar con una palabra de alto nivel (generalmente descriptiva) y terminar con un modificador descriptivo.
Ejemplo:
/* good */
components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- SettingsCheckboxLaunchOnStartup.vue
/* bad */
components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue
2.7 Componentes de cierre automático
[Consejo] Los componentes sin contenido deben cerrarse automáticamente en componentes de un solo archivo, plantillas de cadena y JSX, pero nunca en plantillas DOM.
Los componentes de cierre automático significan que no sólo no tienen contenido, sino que no lo tienen intencionadamente. La diferencia es como una página en blanco de un libro en comparación con una página en blanco con la etiqueta "Esta página se dejó en blanco intencionalmente". Y sin la etiqueta de cierre adicional, su código está más limpio.
Ejemplo:
/* good */
<!-- 在单文件组件、字符串模板和 JSX 中 -->
<MyComponent/>
<!-- 在 DOM 模板中 -->
<my-component></my-component>
/* bad */
<!-- 在单文件组件、字符串模板和 JSX 中 -->
<MyComponent></MyComponent>
<!-- 在 DOM 模板中 -->
<my-component/>
2.8 Caso del nombre del componente
[Consejo] Para la mayoría de los proyectos, los nombres de los componentes siempre deben ser PascalCase en componentes de un solo archivo y plantillas de cadena, pero siempre kebab-case en plantillas DOM. Los nombres de los componentes deben favorecer las palabras completas en lugar de las abreviaturas.
Ejemplo:
/* good */
<!-- 在单文件组件、字符串模板和 JSX 中 -->
<MyComponent/>
<!-- 在 DOM 模板中 -->
<my-component></my-component>
/* bad */
<!-- 在单文件组件、字符串模板和 JSX 中 -->
<MyComponent></MyComponent>
<!-- 在 DOM 模板中 -->
<my-component/>
2.9 Caso del nombre del accesorio
[Consejo] Al declarar accesorios, sus nombres siempre deben usar camelCase, y en plantillas y JSX siempre deben usar kebab-case. Simplemente seguimos las convenciones de cada idioma. Más natural en JavaScript es camelCase. En HTML es kebab-case.
Ejemplo:
/* good */
props: {
greetingText: String
}
<WelcomeMessage greeting-text="hi"/>
/* bad */
props: {
'greeting-text': String
}
<WelcomeMessage greetingText="hi"/>
2.10 Elementos de atributos múltiples
[Consejos] Los elementos con múltiples atributos deben escribirse en varias líneas, una línea para cada atributo.
Ejemplo:
/* good */
<img
src="https://vuejs.org/images/logo.png"
alt="Vue Logo"
>
/* bad */
<img src="https://vuejs.org/images/logo.png" alt="Vue Logo">
2.11 Expresiones simples en plantillas
[Consejo] Las plantillas de componentes solo deben contener expresiones simples, y las expresiones complejas deben refactorizarse en propiedades o métodos calculados.
Ejemplo:
/* good */
<!-- 在模板中 -->
{
{ normalizedFullName }}
// 复杂表达式已经移入一个计算属性
computed: {
normalizedFullName: function () {
return this.fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}
}
/* bad */
{
{
fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}}
2.12 Propiedades calculadas simples
[Consejo] Las propiedades calculadas complejas deben dividirse en tantas propiedades más simples como sea posible.
Ejemplo:
/* good */
computed: {
basePrice: function () {
return this.manufactureCost / (1 - this.profitMargin)
},
discount: function () {
return this.basePrice * (this.discountPercent || 0)
},
finalPrice: function () {
return this.basePrice - this.discount
}
}
/* bad */
computed: {
price: function () {
var basePrice = this.manufactureCost / (1 - this.profitMargin)
return (
basePrice -
basePrice * (this.discountPercent || 0)
)
}
}
2.13 Se debe unificar al máximo el estilo abreviado del comando
[CONSEJO] Las abreviaturas de directivas (v-bind: con:, v-on: con @ y v-slot: con #) deben ser todas o ninguna.
Ejemplo:
/* good */
<input
:value="newTodoText"
:placeholder="newTodoInstructions"
>
/* bad */
<input
v-bind:value="newTodoText"
:placeholder="newTodoInstructions"
>