Melhores práticas do VueJs ?

Riccardo Polacci Blocked Unblock Seguir Seguindo 2 de janeiro

Olá companheiro Devs!

Depois de pesquisar por um tempo nos documentos do VueJs e na web, criei uma lista de melhores práticas e guias de estilo para uma maneira mais correta ou comumente aceita de usar o VueJs.

Os pontos abaixo são alguns deles relacionados à funcionalidade / otimização, outros são convenções de nomenclatura e ordem de elementos do VueJs. Informações mais detalhadas podem ser encontradas nos links do resumo .

Limpar ouvintes de eventos no componente destruir com $off

Ao ouvir eventos com $on , devemos sempre lembrar de remover esse listener com $off em destroyed() . Isso nos impede de ter vazamentos de memória.

Sempre use o caso do kebab para nomes de eventos

Ao emitir / ouvir eventos personalizados, devemos sempre usar o caso do kebab. Por quê? Porque os eventos serão transformados automaticamente no caso do kebab. Nós nunca vamos estar ouvindo um evento em camelCase ou PascalCase, portanto, faz mais sentido declarar o evento da mesma maneira que vamos ouvi-lo: no caso do kebab.

 // Emitting 
this.$emit('my-event') // instead of myEvent
 // Listening 
v-on:my-event

Evite chamar o mesmo método em criado e observe

Se precisarmos disparar um método na inicialização do componente e na alteração de propriedade, a prática comum é fazer algo assim:

 watch: { 
myProperty() {
this.doSomething();
}
},
created() {
this.doSomething();
},
methods: {
doSomething() {
console.log('doing something...');
}
},

Mesmo que pareça correto, o uso de created() aqui é redundante. Podemos colocar toda a nossa funcionalidade em watch , evitando assim ter que duplicar código em created() e ainda acioná-lo na instanciação de componente. Tal como:

 watch: { 
myProperty: {
immediate: true, // forcing handler on initial status
handler() {
this.doSomething();
}
}
},
methods: {
doSomething() {
console.log('doing something...');
}
},
 // Even better solution 
watch: {
myProperty: {
immediate: true, // forcing handler on initial status
handler() {
console.log('doing something...'); // No need to declare a function on methods for 1 use case
}
}
},

Sempre use: chave em loops v-for

É uma prática recomendada comum sempre adicionar uma :key aos loops de seu modelo. Uma chave v-for sem :key pode levar a erros difíceis de encontrar, especialmente com animações.

Use $ _ para propriedades mixins

Mixins são uma ótima maneira de obter código repetido em um único bloco e importá-lo quantas vezes quiser, mas (e é um grande mas) , isso pode levar a vários problemas. Neste ponto, abordaremos a questão das propriedades sobrepostas .

Quando importamos um mixin para o nosso Component, estamos fundindo o código mixin com o código do componente, agora, o que acontece com a propriedade que tem o mesmo nome? O componente sempre terá a vantagem, as propriedades do componente têm maior prioridade.
E se eu quiser que meu mixin tenha mais prioridade? Não é possível atribuir prioridade, mas você pode evitar que as propriedades se sobreponham ou até mesmo sobrescrevendo, escolhendo uma convenção de nomenclatura correta.

Para diferenciar as propriedades mixin das propriedades dos componentes, usamos $_ . Por que esses símbolos? Bem, várias razões:

  1. Convenção do guia de estilo do VueJs
  2. _ é reservado para propriedades privadas da Vue
  3. $ é reservado para o ecossistema do Vue

O que é usado no mixin deve ser colocado dentro do mixin

Na sequência do ponto anterior, os mixins têm outro problema: esquecemos das coisas.

Se nós criarmos um mixin que usa, digamos, this.language e esta propriedade não é definida ou retirada do armazenamento dentro do mixin, então o Component onde o mixin está definido deve conter a propriedade language .

Como você já pode dizer, isso é extremamente propenso a erros. Para evitar esses erros, pegamos o que o mixin precisa dentro da própria mixin. Não se preocupe se pegarmos o material duas vezes, o VueJs é inteligente e não vai funcionar em dobro se detectar que a mesma coisa está sendo tirada da Loja (já que a maioria dos casos vai pegar coisas da Vuex)

Use PascalCase ou kebab-case para componentes de arquivo único

O PascalCase tem uma melhor integração com os editores e permite uma melhor funcionalidade de preenchimento automático / importação entre os IDEs comumente usados.

O caso do kebab é o caminho a percorrer se quisermos evitar problemas com sistemas de arquivos que não diferenciam maiúsculas de minúsculas.

Use o prefixo para os nomes dos componentes base

Componentes apresentados, mudos ou puros devem ter um prefixo que os distinga de outros componentes não puros. Isso melhora muito a legibilidade do projeto e a transferência de conhecimento entre equipes e desenvolvedores.

Use PascalCase para nomes de componentes no JS

Em JavaScript, o PascalCase é a convenção para classes e construtores de protótipos, faz sentido que os componentes do Vue também usem o PascalCase.

Se estivermos usando apenas definições de componentes globais por meio do Vue.component , é recomendável usar o caso do kebab.

Os nomes de sustentação devem sempre usar o camelCase durante a declaração, mas o caso do kebab nos modelos

Seguindo a convenção de cada idioma: JavaScript (camelCase) e HTML (kebab-case) , faz sentido que um prop seja definido em camelCase em JS e usado em kebab-case em HTML.

Use a ordem de opções de componentes no guia de estilo

Pode parecer monótono, mas seguir a mesma ordem para todas as opções de um Componente em todo o projeto ajuda muito ao procurar por coisas e ao criar novos Componentes.

A convenção do VueJs pode ser encontrada no guia de estilo .

Nunca use v-se no mesmo elemento que v-for

Este é um assassino de desempenho, quanto maior a lista, mais desempenho sofrerá com essa prática ruim.

Vamos explicar com código, imagine o seguinte cenário:

 <ul> 
<li
v-for="game in games"
v-if="game.isActive"
:key="game.slug"
>
{{ game.title }}
<li>
</ul>

Será avaliado similar ao seguinte:

 this.games.map(function (game) { 
if (game.isActive) {
return game.title
}
})

Podemos ver aqui que teremos que percorrer toda a lista de games , independentemente de os games ativos terem sido alterados ou não.

Em outros frameworks, como o Angular, essa prática simplesmente não compilaria ( *ngIf não pode ir no mesmo elemento onde existe um *ngFor ) .

Ações devem sempre retornar

Isso é fruto de lutar com async / await e ações Vuex.

Tome o seguinte exemplo:

 // Store 
[SOME_ACTION] () {
// Doing stuff that takes a while
console.log('Action done');
}
 // Consuming action 
async doSomething() {
await dispatch(SOME_ACTION);
console.log('Do stuff now');
}
 This will output: 
// Do stuff now
// Action done

Isto acontece porque await não sabe o que await , pois, ao invés disso, se estamos realmente retornando um Promise.resolve() , o await aguardará a resolução e então seguirá em frente.

 // Store 
[SOME_ACTION] () {
// Doing stuff that takes a while
console.log('Action done');
Promise.resolve();
}
 // Consuming action 
async doSomething() {
await dispatch(SOME_ACTION);
console.log('Do stuff now');
}
 This will output: 
// Action done
// Do stuff now

Use seletores dentro de ações e getters

Criamos seletores por um motivo, não apenas para ser usado em todo o aplicativo, mas também dentro da Vuex Store.

Com o código é melhor explicado:

 // We have this selector 
export const language = (state) => state.userConfig.language;
 // In one of our actions, we need language: 

 // Bad 
[GET_GAMES]({ commit, rootState }) {
const lang = rootState.userConfig.language;
// Do stuff...
}

 // Good 
[GET_GAMES]({ commit, rootState }) {
const lang = language(rootState);
// Do stuff...
}

Resumo

  1. Limpar os ouvintes de eventos no componente destruir com a fonte $ off
  2. Sempre use o caso kebab para a fonte de nomes de evento
  3. Evite chamar o mesmo método na fonte criada e de exibição
  4. Sempre use: key in v-for loops source
  5. Use $ _ para a fonte de propriedades de mixins
  6. O que é usado no mixin deve ser colocado dentro do mixin
  7. Use PascalCase ou kebab-case para fonte de componentes de arquivo único
  8. Use o prefixo para a origem de nomes de componentes base
  9. Use PascalCase para nomes de componentes na fonte JS
  10. Os nomes dos props devem sempre usar o camelCase durante a declaração, mas o caso do kebab na fonte dos templates
  11. Use a ordem de opções de componentes da fonte do guia de estilo
  12. Nunca use v-se no mesmo elemento que v para fonte
  13. Ações devem sempre retornar. Isso evita mal entendido sobre quando a ação é executada.
  14. Use seletores dentro de ações e getters.

Fontes

Obrigado!

Esta postagem foi feita depois de trabalhar com o VueJs com muitos desenvolvedores indo e vindo no mesmo projeto. Seguir estes guias de estilo e práticas recomendadas ajudou a fazer com que todos os novos desenvolvedores se sintam em casa e produzam códigos rapidamente!

Por favor, sinta-se livre para comentar e me dar dicas. Estamos aqui para aprender! ?