ng best practices
1.0.0
Este proyecto tiene como objetivo ser el ejemplo de soporte de un tutorial que lo guía a través de las mejores prácticas de desarrollo frontal (web/móvil) con un ejemplo concreto basado en un proyecto angular.
Para ver que el tutorial llegue lo antes posible, puede votar aquí.
Este proyecto es el resultado de mi experiencia trabajando para ayudar a las nuevas empresas y a las industrias más tradicionales (en finanzas y aeroespacial) definir y desarrollar sus proyectos front-end (Web y Mobule).
He notado que cada vez, una de las partes más difíciles al lanzar un producto es definir las mejores prácticas y encontrar las mejores herramientas para poner en marcha el flujo de trabajo de desarrollo.
Por lo tanto, he decidido crear este proyecto, para ser un concentrado de las mejores prácticas listas para usar fuera de la caja y eso puede ahorrar a los desarrolladores y días de liderazgo/arquitectos técnicos especiales e incluso meses de arduo trabajo para encontrar y definir el mejor flujo de trabajo para sus proyectos.
Este enfoque principal del proyecto/tutorial son las mejores prácticas de desarrollo. Entonces, para el principio, no incluirá ningún material relacionado con la integración continua o la implementación de la aplicación.
Aviso 1: Muchas de las mejores prácticas presentes en este proyecto son, como se mencionó anteriormente, en general al desarrollo frontal e incluso al desarrollo en general (no solo en el front-end), por lo que incluso si no está utilizando Angular en su proyecto, puede recorrerlo para obtener algunas ideas interesantes.
Aviso 2: Puede ver el contenido de diferentes compromisos del proyecto para tener una idea de la evolución del proyecto y los pasos para agregar/incluir una herramienta, biblioteca o patrón específicos para el proyecto.
Este proyecto se generó con Angular CLI versión 7.3.1.
Para este proyecto uso principalmente hilo. Pero puede ejecutar los mismos scripts/comandos usando NPM.
Por ejemplo, para iniciar el proyecto usando yarn , ejecuta yarn start . Para hacer lo mismo usando npm , puede ejecutar npm run start .
Para poder iniciar este proyecto, debe instalar:
npm para ejecutar diferentes scripts. (opcional)Antes de poder iniciar el proyecto, debe instalar las diferentes dependencias/bibliotecas. Para hacerlo, ejecute:
# if npm
npm install
# if yarn
yarn
Aquí hay una lista de herramientas opcionales que puede necesitar en general para el desarrollo de sus proyectos:
La rama principal donde puede encontrar el último código de trabajo y probado es el maestro.
Puede seguir las comodidades y el desarrollo del día a día en la rama de desarrollo.
Un sistema de etiquetado vendrá diferentes actualizaciones y lanzamientos del proyecto.
Ejecute yarn start para un servidor de desarrollo. Navegue a http://localhost:4200/ . La aplicación recargará automáticamente si cambia alguno de los archivos de origen.
Ejecute ng generate component component-name para generar un nuevo componente. También puede usar ng generate directive|pipe|service|class|guard|interface|enum|module .
Ejecute yarn build para construir el proyecto. Los artefactos de construcción se almacenarán en el directorio dist/ . Use la bandera --prod para una construcción de producción.
En realidad, un proyecto generado por Cli Angular predeterminado utiliza la herramienta Karma para las pruebas unitarias. El problema con el karma (puede ser una ventaja en algunos casos), es que necesita lanzar un navegador para ejecutar una prueba que en muchos casos no es necesaria y al mismo tiempo se extiende el tiempo de ejecución de la prueba. Además, puede tener una integración continua integrada en su proceso de desarrollo/entrega que se ejecuta en un entorno donde puede tener un navegador.
Hay una alternativa interesante al Karma que es broma. Hace que sea más rápido y más fácil escribir pruebas. No se necesita navegador. Viene con habilidades de burla y afirmación incorporadas. Además, Jest realiza sus pruebas simultáneamente en paralelo, proporcionando una prueba de prueba más suave y rápida.
Jest-Preset-angular: se usa para facilitar la configuración de la broma. La versión realizada real es 6.0.2, por lo que la documentación y la configuración serán diferentes para las versiones futuras de esta biblioteca.
Ejecute yarn test:all para ejecutar las pruebas unitarias a través de la broma en todo el proyecto.
Si desea ejecutar pruebas unitarias en un proyecto específico como el proyecto connection , ejecute yarn test:connection . No olvide agregar el script necesario a su archivo package.json en Addiion al archivo de configuración de Jest coincidente para poder iniciar la prueba en una nueva biblioteca. Puede tomar el ejemplo de cómo se hace para la biblioteca connection .
También puede iniciar su prueba y observar los cambios ejecutándose para yarn test:all:watch .
VS Code and Jest Depug: si usa el código VS, puede depurar sus pruebas unitarias basadas en JEST agregando un archivo launch.json en su carpeta .vscode (puede encontrar un archivo de ejemplo en el repositorio real). El depurador utilizará el depurador de nodo incorporado. Una documentación más completa puede ser aficionado aquí.
Ejecute yarn e2e para ejecutar las pruebas de extremo a extremo a través del protactor.
Si queremos importar un componente de la biblioteca connection podemos usar la anotación @connection .
Ejemplo: import { ConnectionModule } from '@connection' ;
Esto es posible gracias a la adición del atributo paths al archivo tsconfig.json .
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
...
},
...
} Si queremos obtener más específico sobre la ruta (por ejemplo, en el caso de una dependencia circular), podemos agregar otra ruta al archivo tsconfig.json como el seguimiento:
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
"@connection/*" : [
" projects/connection/src/* "
]
...
},
...
}Permitirá importar componentes u otras funcionalidades exportadas angulares como el siguiente ejemplo:
Ejemplo: import { ConnectionComponent } from '@connection/lib/modules/main/pages'; ;
Para asegurarse de que los desarrolladores sigan un trabajo de trabajo preciso mientras cometen y presionan el código, para que no tenga que hacer verficaciones y ejecutar scripts manualmente, las siguientes herramientas son muy útiles:
En package.json agregas:
" scripts " {
"commit" : " git-cz " ,
...
} Entonces, cuando ejecuta yarn commit se usa el cz-cli . Así que no más git commit .
cz-cli . En package.json agregas:
"config" : {
"commitizen" : {
"path" : " node_modules/cz-customizable "
},
"cz-customizable" : {
"config" : " path/to/custom/cz-config.js "
}
},
... Si no proporciona ningún archivo personalizado en la configuración ( config.cz-customizable.config ), se utilizará el archivo .cz-config.js presente en la raíz del proyecto.
Nota: Para poder usar el código VS para editar comentarios de confirmación de Git u otras tareas de manipulación de archivos en lugar de vim predeterminado, puede ejecutar git config --global core.editor "code --wait" en la condicción de que el código VS está disponible desde la línea Commandoe (puede verificarlo ejecutando code --help ).
Más información aquí.
Agregue la configuración husky en la raíz del archivo package.json :
"husky" : {
"hooks" : {
"pre-commit" : " yarn lintstaged " ,
"prepush" : " yarn prod "
}
} Si desea omitir los hools, simplemente agregue el indicador --no-verify a su comando git. Ejemplo: git push --no-verify
Entonces, a la configuración husky Hooks ya definida, puede agregar el gancho commit-msg :
"husky" : {
"hooks" : {
...,
"commit-msg" : " commitlint -E HUSKY_GIT_PARAMS "
}
} commit-msg Hook le permite compromisos de pelusa antes de que se creen.
Puede agregar un archivo commitlint.config.js en la raíz del proyecto, para definir reglas/convenciones de pelucas.
commitlint.config.js Ejemplo:
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: Si desea volver a intentar una confirmación para que no tenga que volver a ingresar la misma información, simplemente ejecute yarn commit:retry .
Se usó el RouterModule del Angular. La documentación de la angular es muy completa y le aconsejo que lo eche un vistazo.
En este proyecto, he tomado la decisión de que para los proyectos de la app (Standalone), utilizo la enrutamiento/carga directa. Por otro lado, para la aplicación principal (aplicación raíz) el módulo está cargado y afecta la forma en que funciona el enrutamiento.
Para ver cómo se trata la carga de Lzay, puede echar un vistazo al directorio src/app/lazy donde se definen los módulos cargados perezosos. Entonces, estos módulos son "realmente" cargados cargados dentro del archivo src/app/app-routing.module.ts . Para cada módulo cargado perezoso, se define una ruta. Esta ruta debe precedir a todas las rutas definidas en el módulo original.
Exemplo: Supongamos que en su módulo Orignal accede al contenido de la page-one a través del URL localhost:4200/page-one cuando lo carga (como en el proyecto APP/Standalone). Al mismo tiempo, la ruta que ha definido a la carga perezosa del mismo módulo es my-lazy-loaded-path . Por lo tanto, para acceder al mismo contenido/página, debe usar el URL localhost:4200/my-lazy-loaded-path/page-one .
Y aquí para que mi módulo funcione mientras está cargado o cargado directo, se utiliza una combinación de método forRoot sobre el módulo cargado y las variables de entorno.
Cuando se trata de manipular formas, en Angular tienes la opción entre formas reactivas y formas de plantilla.
En la documentación angular oficial que puede encontrar:
Las formas reactivas son más robustas: son más escalables, reutilizables y comprobables. Si los formularios son una parte clave de su aplicación, o ya está utilizando patrones reactivos para construir su aplicación, use formularios reactivos.
Los formularios de plantilla son útiles para agregar un formulario simple a una aplicación, como un formulario de registro de la lista de correo electrónico. Son fáciles de agregar a una aplicación, pero no escalan, así como formas reactivas. Si tiene requisitos de formulario y lógica muy básicos que se pueden administrar únicamente en la plantilla, use formularios basados en plantillas.
Puede encontrar una tabla de diferencias clave aquí.
Para este proyecto, he optado por usar formularios reactivos para todas las ventajas con las que viene, como tener un modelo de datos strcuterado o aprovechar la sincronía entre su plantilla (View/HTML) y su controlador (clase/modelo de componentes). Además, en general, en grandes proyectos, puede tener formas complejas y las reactive forms facilitan la tarea que se las ponga más fáciles.
Cuando inicia su proyecto, puede basarlo primero en una biblioteca de estilo ya existente. Le ayuda a ahorrar tiempo al diseñar su aplicación.
Aquí hay algunos ejemplos de bibliotecas que puede usar:
En realidad, para este proyecto es bootstrap que se usó (no ng-boostrap ).
La mayoría de las bibliotecas como React, Angular, etc. están construidas con una forma para que los componentes administren internamente su estado sin necesidad de una biblioteca o herramienta externa. Le va bien para las aplicaciones con pocos componentes, pero a medida que la aplicación se hace más grande, la gestión de los estados compartidos en los componentes se convierte en una tarea.
En una aplicación donde los datos se comparten entre los componentes, podría ser confuso saber realmente dónde debería vivir un estado. Idealmente, los datos en un componente deben vivir en un solo componente. Por lo tanto, compartir datos entre los componentes hermanos se vuelve difícil (fuente).
La forma en que funciona una biblioteca de gestión estatal es simple. Hay una tienda central que posee todo el estado de la aplicación. Cada componente puede acceder al estado almacenado sin tener que enviar accesorios de un componente a otro.
Por ejemplo, para React, una de las bibliotecas de gestión estatales más utilizadas es Redux. Y el uso del paquete React-Redux lo hace más fácil. Por supuesto, tiene otras bibliotecas de gestión estatales para react como el flujo de Facebook. Entonces, elija lo que más le conviene a que redux se usa más ese flux porque no está centrado en react y puede usarse con cualquier otra biblioteca de vista.
Para angular tiene muchas opciones para la gestión estatal como:
Para Angular , después de estudiar las diferentes opciones, encuentro que ngxs es la mejor opción. Está escrito para Angular en primer lugar, por lo que se implementa siguiendo el estilo del código de Angular y toma y viene la ventaja de la Dependency Injection proporcionada por Angular . Además, es menos detallado que otras bibliotecas. Por estas razones, hemos tomado la decisión de usarlo en muchas empresas con las que trabajé. Puede encontrar aquí una explicación completa de por qué usar ngxs .
Complementos ngxs usados para este repositorio:
El patrón de fachada es un patrón de diseño de software comúnmente utilizado en la programación orientada a objetos. Análogo a una fachada en la arquitectura, una fachada es un objeto que sirve como una interfaz frontal enmascarando un código subyacente o estructural más complejo. Una fachada puede:
Si bien esto parece un cambio bastante trivial (y una capa adicional), la fachada tiene un gran impacto positivo de la productividad del desarrollador y produce significativamente menos complejidad en las capas de vista (fuente).
Otra ventaja es que hace que sus controladores (componentes angulares, por ejemplo), independientes de la biblioteca de gestión estatal que haya elegido usar.
Para la internacionalización tiene dos opciones:
1 - Use el sistema I18N de Angular
2 - Use la biblioteca NGX -Translate.
No entraré en detalles, pero la elección de este proyecto y muchos otros proyectos de producción fue usar ngx-translate . Las principales razones son que, para el mismo resultado, es más simple usar y desarrollar con y Angular i18n lo obliga a construir la aplicación por idioma y recarga la aplicación sobre el cambio de idioma.
Para obtener más ayuda sobre la CLI angular, use ng help o vaya a ver el readme de CLI angular.
Si está utilizando el código VS, puede encontrar los siguientes complementos muy útiles:
Copyright por @Haythem-ouederni. Todas las fuentes del proyecto se publican bajo la licencia de licencia Apache.
