VueJs Style Guide - Criando aplicações manuteníveis

Slide 1

Slide 1 text

VueJs Style Guide Criando aplicações manuteníveis

Slide 2

Slide 2 text

*/omarkdev

Slide 3

Slide 3 text

Categorias A B C D Essencial Altamente recomendadas Recomendadas Use com cautela

Slide 4

Slide 4 text

Prevenindo erros A

Slide 5

Slide 5 text

Nomes de componentes com multi-palavras 1.

Slide 6

Slide 6 text

“Nomes de componentes devem ser sempre multi-palavras, exceto o componente raiz”

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Propriedade “data” no componente 2.

Slide 10

Slide 10 text

“A propriedade ‘data’ deve ser uma função, exceto no ‘new Vue’”

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Por que precisa ser uma função?

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

Definindo “prop” 3.

Slide 16

Slide 16 text

“A definição de propriedades deve ser a mais detalhada possível, especificando pelo menos o seu tipo”

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Mas por quê?

Slide 21

Slide 21 text

- Facilidade na leitura da utilização; - Receber notificação em desenvolvimento se possui um formato inválido.

Slide 22

Slide 22 text

Uso do “key” no “v-for” 4.

Slide 23

Slide 23 text

“Sempre use o atributo key com v-for”

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Explicação detalhada

Slide 27

Slide 27 text

Estilos com escopos em componentes 5.

Slide 28

Slide 28 text

“Em aplicações os estilos para componentes de alto nível “App” devem ser globais, mas os outros devem utilizar o scope”

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Imagine o seguinte caso

Slide 34

Slide 34 text

Melhorando a legibilidade B

Slide 35

Slide 35 text

Cada componente um arquivo 1.

Slide 36

Slide 36 text

“Sempre que houver um sistema de compilação para concatenar arquivos, cada componente deve estar em seu próprio arquivo.”

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Nome de componente base 2.

Slide 40

Slide 40 text

“Componentes base que se aplicam a estilos e convenções específicos da aplicação, tais como Base, App, ou V.”

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Esses componentes devem conter somente - Elementos HTML; - Outros componentes base; - Estados locais; - Elementos de UI de terceiros.

Slide 44

Slide 44 text

Vantagens - Ao listar por ordem alfabética, os componentes serão listados juntos; - Como os componentes precisam ser multi palavras, a convenção evita prefixos arbitrários; - Os componentes são sempre utilizados, então você pode torná-los globais.

Slide 45

Slide 45 text

Nomes de componente de instância única 3.

Slide 46

Slide 46 text

“Componentes que devem ter somente uma única instância ativa devem começar com o prefixo The, para determinar que eles podem ser somente um”

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

Isso não quer dizer que os componentes são utilizados em uma única página

Slide 50

Slide 50 text

Quer dizer que é somente utilizado uma vez a cada página.

Slide 51

Slide 51 text

Ordem das palavras no nome de componentes 4.

Slide 52

Slide 52 text

“Nomes de componentes devem começar com a palavra de mais alto nível e terminar com palavras que descrevem modificações.”

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

“Porque eu devo forçar nomes de componentes com uma linguagem menos natural?”

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

Separar por pastas também é uma opção - Geralmente leva-se mais tempo para navegar entre sub-diretórios do que componentes na mesma pasta; - Conflitos em nomes, pode se tornar mais difícil navegar no editor; - Refatoração se torna mais complexa, pois nem sempre substituir é suficiente para alterar as referências.

Slide 59

Slide 59 text

Minimizando opções arbitrárias C

Slide 60

Slide 60 text

Ordem das propriedades de um componente/instância 1.

Slide 61

Slide 61 text

“As propriedades de componente/instância devem ser ordenadas consistentemente.”

Slide 62

Slide 62 text

- functional 3. Tipo de componente (altera o tipo de componente) - el 1. Efeitos Externos (efeitos fora do componente) - name - parent 2. Nível global (requer conhecimento fora do componente) - delimiters - comments 4. Modificadores de template (muda forma como é compilado)

Slide 63

Slide 63 text

- components - directives - filters 5. Dependência de template (assets) - extends - mixins 6. Composição (merge das propriedades) - inheritAttrs - model - props/propsData 7. Interface (a interface do componente)

Slide 64

Slide 64 text

- methods - data - computed 8. Estado local (propriedades reativas locais) - watch - beforeCreate - created - beforeMount - mounted - beforeUpdate 9. Eventos (callbacks disparados atráves de eventos reativos) - updated - activated - deactivated - beforeDestroy - destroyed 10. Propriedades não reativas (propriedades independentes do sistema reativo)

Slide 65

Slide 65 text

- template/render - renderError 11. Renderização (A descrição declarativa da saída)

Slide 66

Slide 66 text

Linhas vazias em componentes/instâncias 2.

Slide 67

Slide 67 text

“Você pode adicionar uma linha vazia entre as propriedades de várias linhas.”

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

Ordem dos elementos de um componente de arquivo único “.vue” 3.

Slide 70

Slide 70 text

“Componentes de arquivo único devem sempre ter a ordem script, template, e style”

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

Padrões potencialmente perigosos D

Slide 74

Slide 74 text

Seletores de elemento com scoped 1.

Slide 75

Slide 75 text

“Os seletores de elemento devem ser evitados quando usados com scoped.”

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

Explicação detalhada

Slide 79

Slide 79 text

Como o scoped funciona

Slide 80

Slide 80 text

Gerenciamento de estado sem fluxo 2.

Slide 81

Slide 81 text

“Vuex deve ser preferido para o gerenciamento de estado global, em vez de this.$root ou um o uso de event bus.”