ng best practices
1.0.0
Ce projet vise à être l'exemple de support d'un tutoriel vous guidant à travers les meilleures pratiques de développement frontal (Web / mobile) avec un exemple concrète basé sur un projet angulaire.
Pour voir le tutoriel venir dès que possible, vous pouvez voter ici.
Ce projet est le résultat de mon expérience de travail sur les startups et les industries plus traditionnelles (en finance et aérospatiale) définissant et développement de leurs projets frontaux (Web et Mobule).
J'ai remarqué que chaque fois, l'une des parties les plus difficiles lors du lancement d'un produit est de définir les meilleures pratiques et de trouver les meilleurs outils pour mettre en place le flux de travail de développement.
J'ai donc décidé de créer ce projet, d'être un concentré de meilleures pratiques prêtes à l'emploi et de sauver les développeurs et les jours d'architectes techniques / architectes techniques et même des mois pour trouver et définir le meilleur flux de travail pour leurs projets.
Cet objectif principal du projet / tutoriel est les meilleures pratiques de développement. Ainsi, pour le début, il n'inclura aucun matériel lié à l'intégration continue ou au déploiement d'applications.
AVIS 1: Beaucoup des meilleures pratiques présentes dans ce projet sont, comme mentionnées précédemment, générales au développement frontal et même au développement en général (pas seulement front-end), donc même si vous n'utilisez pas angulaire dans votre projet, vous pouvez le parcourir pour obtenir des idées intéressantes.
AVIS 2: Vous pouvez voir le contenu de différents projets s'engager à avoir une idée de l'évolution du projet et des étapes à ajouter / inclure un outil, une bibliothèque ou un modèle spécifique au projet.
Ce projet a été généré avec Angular CLI version 7.3.1.
Pour ce projet, j'utilise principalement du fil. Mais vous pouvez exécuter les mêmes scripts / commandes à l'aide de NPM.
Par exemple, pour démarrer le projet à l'aide yarn , vous exécutez yarn start . Pour faire la même chose en utilisant npm , vous pouvez exécuter npm run start .
Pour pouvoir lancer ce projet, vous devez installer:
npm pour exécuter différents scripts. (facultatif)Avant de pouvoir démarrer le projet, vous devez installer les différentes dépendances / bibliothèques. Pour ce faire, courez:
# if npm
npm install
# if yarn
yarn
Voici une liste d'outils facultatifs dont vous pourriez avoir besoin en général pour le développement de vos projets:
La branche principale où vous pouvez trouver le dernier code de travail et testé est le maître.
Vous pouvez suivre les engagements et le développement quotidiens sur la branche Develop.
Un système de marquage se présentera dans différentes mises à niveau et versions du projet.
Exécutez yarn start pour un serveur de développement. Accédez à http://localhost:4200/ . L'application se rechargera automatiquement si vous modifiez l'un des fichiers source.
Exécutez ng generate component component-name pour générer un nouveau composant. Vous pouvez également utiliser ng generate directive|pipe|service|class|guard|interface|enum|module .
Exécutez yarn build pour construire le projet. Les artefacts de construction seront stockés dans le dist/ Directory. Utilisez le drapeau --prod pour une construction de production.
En fait, un projet généré par-CLI par défaut utilise un outil Karma pour les tests unitaires. Le problème avec le karma (cela peut être un avantage dans certains cas), c'est qu'il doit lancer un navigateur pour exécuter un test qui, dans de nombreux cas, n'est pas nécessaire et prolonge en même temps le temps d'exécution du test. De plus, vous pouvez avoir une intégration continue intégrée à votre processus de développement / livraison qui fonctionne sur un environnement où vous pouvez avoir un navigateur.
Il existe une alternative intéressante au Karma qui est une plaisanterie. Il est plus rapide et plus facile d'écrire des tests. Aucun navigateur n'est nécessaire. Il est livré avec des capacités de moquerie et d'affirmation intégrées. De plus, JEST exécute vos tests simultanément en parallèle, fournissant un essai plus fluide et plus rapide.
JEST-PRESET-ANGULAR: Utilisé pour faciliter la configuration de la plaisanterie. La version réelle utilisée est 6.0.2, donc la documentation et la configuration seront différentes pour les versions futur de cette bibliothèque.
Exécutez yarn test:all pour exécuter les tests unitaires via une plaisanterie sur l'ensemble du projet.
Si vous souhaitez exécuter des tests unitaires dans un projet spécifique comme le projet connection Exécutez yarn test:connection . N'oubliez pas d'ajouter le script nécessaire à votre fichier package.json dans Addiion au fichier de configuration de la plaisanterie correspondant pour pouvoir lancer le test dans une nouvelle bibliothèque. Vous pouvez prendre l'exemple de la façon dont cela se fait pour la bibliothèque connection .
Vous pouvez également lancer vos tests et surveiller les modifications en fonctionnant pour Exmaple yarn test:all:watch .
VS CODE ET DE DÉBUG: Si vous utilisez VS Code, vous pouvez déboguer vos tests unitaires basés sur la plaisanterie en ajoutant un fichier launch.json sous votre dossier .vscode (vous pouvez trouver un exemple de fichier dans le ré-ré-repo). Le débogueur utilisera le débogueur de nœud intégré. Une documentation plus complète peut être aimée ici.
Exécutez yarn e2e pour exécuter les tests de bout en bout via le protracteur.
Si nous souhaitons importer un composant à partir de la bibliothèque connection nous pouvons utiliser l'annotation @connection .
Exemple: import { ConnectionModule } from '@connection' ;
Cela est possible grâce à l'ajout de l'attribut paths au fichier tsconfig.json .
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
...
},
...
} Si nous voulons être plus précis sur le chemin (par exemple en cas de dépendance circulaire), nous pouvons ajouter un autre chemin au fichier tsconfig.json comme suivre:
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
"@connection/*" : [
" projects/connection/src/* "
]
...
},
...
}Il permettra d'importer des composants ou d'autres fonctionnalités angulaires exportées comme l'exemple suivant:
Exemple: import { ConnectionComponent } from '@connection/lib/modules/main/pages'; ;
Pour s'assurer que les développeurs suivent un travail de travail précis tout en combler et en poussant le code, afin que vous n'ayez pas à faire de verfications et à exécuter les scripts manuellement, les outils suivants sont très utiles:
Dans package.json vous ajoutez:
" scripts " {
"commit" : " git-cz " ,
...
} Ainsi, lorsque vous exécutez yarn commit le cz-cli est utilisé. Donc plus de git commit directs.
cz-cli . Dans package.json vous ajoutez:
"config" : {
"commitizen" : {
"path" : " node_modules/cz-customizable "
},
"cz-customizable" : {
"config" : " path/to/custom/cz-config.js "
}
},
... Si vous ne donnez aucun fichier personnalisé dans la configuration ( config.cz-customizable.config ), le fichier .cz-config.js présent à la racine du projet sera utilisé.
Remarque: Pour pouvoir utiliser VS Code pour modifier les commentaires GIT Commit ou d'autres tâches de manipulation de fichiers au lieu de vim par défaut, vous pouvez exécuter git config --global core.editor "code --wait" à la condiction que le code vs est disponible à partir de la ligne commande (vous pouvez le vérifier en exécutant code --help ).
Plus d'informations ici.
Ajoutez la configuration husky à la racine du fichier package.json :
"husky" : {
"hooks" : {
"pre-commit" : " yarn lintstaged " ,
"prepush" : " yarn prod "
}
} Si vous voulez sauter le hools, ajoutez l'indicateur --no-verify à votre commande git. Exemple: git push --no-verify
Ainsi, pour la configuration de husky Hooks déjà définie, vous pouvez ajouter le crochet commit-msg :
"husky" : {
"hooks" : {
...,
"commit-msg" : " commitlint -E HUSKY_GIT_PARAMS "
}
} commit-msg Hook vous permet de commits de peluches avant d'être créés.
Vous pouvez ajouter un fichier commitlint.config.js à la racine du projet, pour définir des règles / conventions de liaison.
commitlint.config.js Exemple:
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' ]
] ,
...
}
} ; Remarque: Si vous souhaitez réessayer un engagement afin que vous n'ayez pas à réintégrer les mêmes informations, exécutez-le, yarn commit:retry .
Le routermodule de l'Angular a été utilisé. La documentation de l'Angular est très complète et je vous conseille de y jeter un œil.
Dans ce projet, j'ai fait le choix que pour app (s) projet (s) autonome), j'utilise le routage / chargement direct. D'un autre côté, pour l'application principale (application racine), le module est chargé paresseux et il affecte le fonctionnement du routage.
Pour voir comment, le chargement de Lzay est traité, vous pouvez jeter un œil au répertoire src/app/lazy où les modules chargés paresseux sont définis. Ensuite, ces modules sont "vraiment" chargés de paresseux dans le fichier src/app/app-routing.module.ts . Pour chaque module chargé paresseux, un chemin est défini. Ce chemin doit précéder tous les chemins définis dans le module d'origine.
Exemple: Supposons que dans votre module d'origine, vous accédez au contenu page-one via l'URL localhost:4200/page-one lorsque vous le chargez direct (comme dans le projet App / Standalone). Dans le même temps, le chemin que vous avez défini pour charger paresseux le même module est my-lazy-loaded-path . Donc, pour accéder au même contenu / page, vous devez utiliser l'URL localhost:4200/my-lazy-loaded-path/page-one à la place.
Et ici pour faire fonctionner mon module tout en étant chargé ou chargé direct, une combinaison de méthode forRoot sur le module chargé et les variables d'environnement est utilisée.
En ce qui concerne la manipulation des formes, en angulaire, vous avez le choix entre les formes réactives et les formes axées sur les modèles.
Dans la documentation angulaire officielle, vous pouvez trouver:
Les formes réactives sont plus robustes: elles sont plus évolutives, réutilisables et testables. Si les formulaires sont un élément clé de votre application ou si vous utilisez déjà des modèles réactifs pour créer votre application, utilisez des formulaires réactifs.
Les formulaires axés sur les modèles sont utiles pour ajouter un formulaire simple à une application, comme un formulaire d'inscription de liste de messagerie. Ils sont faciles à ajouter à une application, mais ils n'échellent pas aussi bien que des formes réactives. Si vous avez des exigences de formulaire et une logique très basiques qui peuvent être gérées uniquement dans le modèle, utilisez des formulaires axés sur le modèle.
Vous pouvez trouver un tableau des principales différences ici.
Pour ce projet, j'ai choisi d'utiliser des formulaires réactifs pour tous les avantages qu'il comporte comme avoir un modèle de données strcuté ou profiter de la synchronicité entre votre modèle (View / HTML) et votre contrôleur (classe de composants / modèle). En outre, en général, dans les grands projets, vous pouvez avoir des formes complexes et les reactive forms facilitent la tâche pour vous.
Lorsque vous lancez votre projet, vous pouvez le baser d'abord sur une bibliothèque de style déjà existante. Il vous aide à gagner du temps lors du style de votre application.
Voici quelques exemples de bibliothèques que vous pouvez utiliser:
En fait, pour ce projet, c'est bootstrap qui a été utilisé (pas ng-boostrap ).
La plupart des bibliothèques comme React, Angular, etc. sont construites avec un moyen pour les composants de gérer en interne leur état sans avoir besoin d'une bibliothèque ou d'un outil externe. Il fait bien pour les applications avec peu de composants, mais à mesure que l'application augmente, la gestion des États partagés entre les composants devient une corvée.
Dans une application où les données sont partagées entre les composants, il pourrait être déroutant de savoir réellement où un État devrait vivre. Idéalement, les données d'un composant doivent vivre dans un seul composant. Le partage de données entre les composants entre frères et sœurs devient donc difficile (source).
Le fonctionnement d'une bibliothèque de gestion d'État est simple. Il existe un magasin central qui contient tout l'état de la demande. Chaque composant peut accéder à l'état stocké sans avoir à envoyer des accessoires d'un composant à un autre.
Par exemple, pour réagir, l'une des bibliothèques de gestion d'État les plus utilisées est Redux. Et l'utilisation du package React-Redux le facilite. À coup sûr, vous avez d'autres bibliothèques de gestion d'État pour react comme Facebook's Flux. Choisissez donc ce qui vous convient le plus que redux est plus utilisé ce flux car il n'est pas centré sur react et peut être utilisé avec n'importe quelle autre bibliothèque de vue.
Pour angular vous avez de nombreuses options pour la gestion de l'État comme:
Pour Angular , après avoir étudié les différentes options, je trouve que ngxs est la meilleure option. Il est écrit pour Angular en premier lieu, il est donc mis en œuvre en suivant le style de code de l'Angular et profite de l' Dependency Injection fournie par Angular . De plus, il est moins verbeux que d'autres bibliothèques. Pour ces raisons, nous avons fait le choix de l'utiliser dans de nombreuses entreprises avec lesquelles j'ai travaillé. Vous pouvez trouver ici une explication complète de la raison pour laquelle utiliser ngxs .
Plugins ngxs utilisés pour ce dépôt:
Le modèle de façade est un modèle de conception logicielle couramment utilisé dans la programmation orientée objet. Analogue à une façade en architecture, une façade est un objet qui sert d'interface orientée vers l'avant masquant un code sous-jacent ou structurel plus complexe. Une façade peut:
Bien que cela semble être un changement plutôt trivial (et une couche supplémentaire), la façade a un impact positif énorme de la productivité des développeurs et donne beaucoup moins de complexité dans les couches de vue (source).
Un autre avantage est qu'il fait de vos contrôleurs (composants angulaires par exemple), indépendants de la bibliothèque de gestion de l'État que vous avez choisi d'utiliser.
Pour l'internationalisation, vous avez deux options:
1 - Utilisez le système I18N d'Angular
2 - Utilisez la bibliothèque NGX-Translate.
Je n'entrerai pas dans les détails, mais le choix de ce projet et de nombreux autres projets comme des projets était d'utiliser ngx-translate . Les principales raisons sont que, pour le même résultat, il est plus simple à utiliser et à développer avec et Angular i18n vous oblige à créer l'application par langue et il recharge l'application sur le changement de langue.
Pour obtenir plus d'aide sur la CLI angulaire, utilisez ng help ou allez consulter la lecture Angular CLI.
Si vous utilisez VS Code, vous pouvez trouver les plugins suivants très utiles:
Copyright par @ haythem-ouernerni. Toutes les sources de projet sont publiées sous la licence Apache.
