ng best practices
1.0.0
Este projeto tem como objetivo ser o exemplo de suporte de um tutorial que você pode levar você a práticas recomendadas de desenvolvimento de front-end (Web/Mobile) com um exemplo concreto com base em um projeto angular.
Para ver o tutorial , o mais rápido possível, você pode votar aqui.
Este projeto é o resultado da minha experiência trabalhando para ajudar as startups e as indústrias mais tradicionais (em finanças e aeroespacial) definindo e desenvolvendo seus projetos de front-end (Web e Mobule).
Percebi que, toda vez, uma das partes mais difíceis ao lançar um produto está definindo as melhores práticas e encontrando as melhores ferramentas para implementar o fluxo de trabalho de desenvolvimento.
Por isso, decidi criar este projeto, para ser um concentrado de práticas recomendadas prontas para uso fora da caixa e que possa salvar os desenvolvedores e os dias de líderes de tecnologia/tecnologia técnica e até meses de trabalho duro para encontrar e definir o melhor fluxo de trabalho para seus projetos.
Este foco principal do projeto/tutorial é o desenvolvimento das melhores práticas. Portanto, para o início, não incluirá qualquer material relacionado à integração contínua ou implantação de aplicativos.
Aviso 1: Muitas das melhores práticas presentes neste projeto são, como mencionado anteriormente, em geral para o desenvolvimento do front-end e até para o desenvolvimento em geral (não apenas o front-end); portanto, mesmo se você não estiver usando o Angular em seu projeto, você pode percorrer-lo para obter algumas idéias interessantes.
Aviso 2: Você pode ver o conteúdo de um projeto diferente se comprometendo a ter uma idéia da evolução do projeto e as etapas para adicionar/incluir uma ferramenta, biblioteca ou padrão específico ao projeto.
Este projeto foi gerado com a versão angular da CLI 7.3.1.
Para este projeto, uso principalmente fios. Mas você pode executar os mesmos scripts/comandos usando o NPM.
Por exemplo, para iniciar o projeto usando yarn você executa yarn start . Para fazer a mesma coisa usando npm , você pode executar npm run start .
Para poder lançar este projeto, você precisa instalar:
npm para executar scripts diferentes. (opcional)Antes de poder iniciar o projeto, você deve instalar as diferentes dependências/bibliotecas. Fazer isso correr:
# if npm
npm install
# if yarn
yarn
Aqui está uma lista de ferramentas opcionais que você pode precisar em geral para o desenvolvimento de seus projetos:
A filial principal, onde você pode encontrar o código mais recente de trabalho e testado é o mestre.
Você pode seguir os compromissos do dia a dia e o desenvolvimento na filial Desenvolvimento.
Um sistema de marcação ocorrerá em diferentes atualizações e lançamentos do projeto.
Execute yarn start para um servidor de dev. Navegue para http://localhost:4200/ . O aplicativo recarregará automaticamente se você alterar algum dos arquivos de origem.
Executar ng generate component component-name para gerar um novo componente. Você também pode usar ng generate directive|pipe|service|class|guard|interface|enum|module .
Execute yarn build para construir o projeto. Os artefatos de construção serão armazenados no dist/ Diretório. Use o sinalizador --prod para uma construção de produção.
Na verdade, um projeto gerado por cli angular padrão usa ferramenta de karma para testes de unidade. O problema com o karma (pode ser uma vantagem em alguns casos) é que ele precisa iniciar um navegador para executar um teste que, em muitos casos, não é necessário e, ao mesmo tempo, estende o tempo de execução do teste. Além disso, você pode ter integração contínua integrada ao processo de desenvolvimento/entrega que é executado em um ambiente onde você pode ter um navegador.
Há uma alternativa interessante ao Karma que é uma brincadeira. Isso torna mais rápido e mais fácil escrever testes. Nenhum navegador é necessário. Ele vem com habilidades embutidas de zombaria e afirmação. Além disso, o Jest executa seus testes simultaneamente em paralelo, fornecendo uma execução de teste mais suave e rápida.
JEST-PRESET-Angular: Usado para facilitar a configuração do jest. A versão usada real é 6.0.2, portanto, a documentação e a configuração serão diferentes para as versões futurs desta biblioteca.
Execute yarn test:all para executar os testes de unidade via JEST em todo o projeto.
Se você deseja executar testes de unidade em um projeto específico, como o Projeto connection Executar yarn test:connection . Não se esqueça de adicionar o script necessário ao seu arquivo package.json no addiion ao arquivo de configuração do JEST correspondente para poder iniciar o teste em uma nova biblioteca. Você pode dar o exemplo de como é feito para a biblioteca connection .
Você também pode iniciar os testes e observar as alterações em execução para o Exmaple yarn test:all:watch .
VS Código e Jest Debug: Se você usar o código VS, poderá depurar seus testes de unidade baseados em JEST adicionando um arquivo de launch.json na sua pasta .vscode (você pode encontrar um arquivo de exemplo no repo real). O depurador usará o depurador de nós embutido. Uma documentação mais completa pode gostar aqui.
Execute yarn e2e para executar os testes de ponta a ponta via transferidor.
Se queremos importar um componente da Biblioteca connection podemos usar a anotação @connection .
Exemplo: import { ConnectionModule } from '@connection' ;
Isso é possível graças à adição do atributo paths ao arquivo tsconfig.json .
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
...
},
...
} Se quisermos ficar mais específicos sobre o caminho (por exemplo, em caso de dependência circular), podemos adicionar um outro caminho ao arquivo tsconfig.json como seguir:
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
"@connection/*" : [
" projects/connection/src/* "
]
...
},
...
}Permitirá importar componentes ou outras funcionalidades exportadas angulares, como o exemplo a seguir:
Exemplo: import { ConnectionComponent } from '@connection/lib/modules/main/pages'; ;
Para garantir que os desenvolvedores sigam um fluxo de trabalho preciso enquanto cometem e pressionam o código, para que você não precise fazer verficações e executar scripts manualmente, as seguintes ferramentas são muito úteis:
No package.json você adiciona:
" scripts " {
"commit" : " git-cz " ,
...
} Então, quando você executa yarn commit o cz-cli é usado. Portanto, não há mais git commit .
cz-cli . No package.json você adiciona:
"config" : {
"commitizen" : {
"path" : " node_modules/cz-customizable "
},
"cz-customizable" : {
"config" : " path/to/custom/cz-config.js "
}
},
... Se você não fornecer nenhum arquivo personalizado na configuração ( config.cz-customizable.config ), o arquivo .cz-config.js presente na raiz do projeto será usado.
NOTA: Para poder usar o código VS para editar comentários de comprometimento do GIT ou outras tarefas de manipulação de arquivos em vez do vim padrão, você pode executar git config --global core.editor "code --wait" no Condicionamento de que o código VS está disponível na linha de comando (você pode verificá -lo executando code --help ).
Mais informações aqui.
Adicione a configuração husky na raiz do arquivo package.json :
"husky" : {
"hooks" : {
"pre-commit" : " yarn lintstaged " ,
"prepush" : " yarn prod "
}
} Se você deseja pular os hools, basta adicionar o sinalizador --no-verify ao seu comando git. Exemplo: git push --no-verify
Portanto, para a configuração de ganchos husky já definida, você pode adicionar o gancho commit-msg :
"husky" : {
"hooks" : {
...,
"commit-msg" : " commitlint -E HUSKY_GIT_PARAMS "
}
} O gancho commit-msg permite que você se comprometa antes de serem criados.
Você pode adicionar um arquivo commitlint.config.js na raiz do projeto, para definir regras/convenções de linha.
Exemplo commitlint.config.js :
module . exports = {
// we use the default @commitlint/config-conventional rules.
// you have to install @commitlint/config-conventional library to be able to use it.
extends : [ '@commitlint/config-conventional' ] ,
// Any rules defined here will override rules from @commitlint/config-conventional
// => custom rules
rules : {
'header-max-length' : [ 2 , 'always' , 100 ] ,
'subject-case' : [
2 ,
'never' ,
[ 'sentence-case' , 'start-case' , 'pascal-case' , 'upper-case' ]
] ,
...
}
} ; NOTA: Se você deseja tentar novamente uma confirmação, para não precisar entrar novamente nas mesmas informações, basta executar yarn commit:retry .
Foi utilizado o Routermodule do Angular. A documentação do Angular é muito completa e eu aconselho você a dar uma olhada nela.
Neste projeto, fiz a opção de que, para o (s) projeto (s) app (s), uso o roteamento/carregamento direto. Por outro lado, para o aplicativo principal (aplicativo root), o módulo é carregado preguiçoso e afeta a maneira como o roteamento funciona.
Para ver como o carregamento do lzay é tratado, você pode dar uma olhada no diretório src/app/lazy onde os módulos carregados preguiçosos são definidos. Em seguida, esses módulos são "realmente" preguiçosos carregados no arquivo src/app/app-routing.module.ts . Para cada módulo carregado preguiçoso, um caminho é definido. Este caminho deve preceder todos os caminhos definidos no módulo original.
Exemplo: suponha que, no seu módulo orignal, você acessa o conteúdo page-one por meio do URL localhost:4200/page-one quando você o direciona (como no projeto App/Standalone). Ao mesmo tempo, o caminho que você definiu para carregar preguiçoso que o mesmo módulo é my-lazy-loaded-path . Portanto, para acessar o mesmo conteúdo/página, você deve usar o URL localhost:4200/my-lazy-loaded-path/page-one .
E aqui para fazer meu módulo funcionar enquanto carregado ou carregado direto, é usada uma combinação do método forRoot sobre o módulo carregado e as variáveis de ambiente.
Quando se trata de manipular as formas, no Angular, você tem a escolha entre formas reativas e formas orientadas a modelos.
Na documentação angular oficial que você pode encontrar:
As formas reativas são mais robustas: são mais escaláveis, reutilizáveis e testáveis. Se os formulários forem uma parte essencial do seu aplicativo ou você já está usando padrões reativos para criar seu aplicativo, use formulários reativos.
Os formulários orientados a modelos são úteis para adicionar um formulário simples a um aplicativo, como um formulário de inscrição na lista de e-mails. Eles são fáceis de adicionar a um aplicativo, mas não são escalados tão bem quanto formas reativas. Se você tiver requisitos e lógica de formulário muito básicos que possam ser gerenciados apenas no modelo, use formulários orientados a modelos.
Você pode encontrar uma tabela de diferenças importantes aqui.
Para este projeto, optei por usar formas reativas para todas as vantagens que ele vem como ter um modelo de dados estripados ou aproveitar a sincronicidade entre o seu modelo (View/html) e seu controlador (classe/modelo de componente). Além disso, geralmente, em grandes projetos, você pode ter formas complexas e as reactive forms facilitam a construção da tarefa.
Ao iniciar seu projeto, você pode baseá -lo primeiro em uma biblioteca de estilo já existente. Ajuda você a economizar tempo ao estilo do seu aplicativo.
Aqui estão alguns exemplos de bibliotecas que você pode usar:
Na verdade, para este projeto, é bootstrap que foi usado (não ng-boostrap ).
A maioria das bibliotecas como React, Angular etc. é construída com uma maneira de os componentes gerenciarem internamente seu estado, sem a necessidade de uma biblioteca ou ferramenta externa. Ele faz bem para aplicativos com poucos componentes, mas à medida que o aplicativo aumenta, os estados gerenciais compartilhados entre os componentes se tornam uma tarefa árdua.
Em um aplicativo em que os dados são compartilhados entre os componentes, pode ser confuso saber onde um estado deve morar. Idealmente, os dados em um componente devem viver em apenas um componente. Portanto, o compartilhamento de dados entre os componentes do irmão se torna difícil (fonte).
A maneira como uma biblioteca de gerenciamento de estado funciona é simples. Há uma loja central que mantém todo o estado do aplicativo. Cada componente pode acessar o estado armazenado sem precisar enviar adereços de um componente para outro.
Por exemplo, para o React, uma das bibliotecas de gerenciamento de estado mais usadas é redux. E o uso do pacote React-Redux facilita. Com certeza, você tem outras bibliotecas de gerenciamento de estados para react como o fluxo do Facebook. Portanto, escolha o que mais se adequa a você, o redux é mais usado esse flux , pois não está centrado no react e pode ser usado com qualquer outra biblioteca de visualização.
Para angular você tem muitas opções para gerenciamento de estado como:
Para Angular , depois de estudar as diferentes opções, acho que ngxs é a melhor opção. Está escrito para Angular em primeiro lugar, para que seja implementado seguindo o estilo de código do Angular e assuma a vantagem da Dependency Injection fornecida pelo Angular . Além disso, é menos detalhado que outras bibliotecas. Por esses motivos, fizemos a opção de usá -lo em muitas empresas com quem trabalhei. Você pode encontrar aqui uma explicação completa de por que usar ngxs .
Utilizou os plugins ngxs para este repositório:
O padrão de fachada é um padrão de design de software comumente usado na programação orientada a objetos. Análogo a uma fachada na arquitetura, uma fachada é um objeto que serve como uma interface frontal mascarando o código subjacente ou estrutural mais complexo. Uma fachada pode:
Embora isso pareça uma mudança bastante trivial (e uma camada extra), a fachada tem um enorme impacto positivo da produtividade do desenvolvedor e produz significativamente menos complexidade nas camadas de visão (fonte).
Uma outra vantagem é que ele torna seus controladores (componentes angulares, por exemplo), independente da Biblioteca de Gerenciamento de Estado que você escolheu para usar.
Para a internacionalização, você tem duas opções:
1 - Use o sistema I18N do Angular
2 - Use biblioteca NGX -Translate.
Não vou entrar em detalhes, mas a escolha para este projeto e muitos outros projetos de produção era usar ngx-translate . Os principais motivos são que, para o mesmo resultado, é mais simples de usar e desenvolver com e Angular i18n o força a criar o aplicativo por idioma e ele recarrega o aplicativo na mudança de idioma.
Para obter mais ajuda na CLI angular, use ng help ou vá conferir o Angular CLI ReadMe.
Se você estiver usando o código VS, poderá encontrar os seguintes plugins muito úteis:
Direitos autorais de @haythem-ouederni. Todas as fontes do projeto são divulgadas sob a licença da Apache.
