Estructura y Buenas pr谩cticas - Angular
Nota
Antes de empezar y para puntualizar, Angular se considera un framework SPA Single-page application.
En esta parte vamos a explicar los fundamentos de un proyecto en Angular y las recomendaciones existentes.
Estructura y funcionamiento
Ciclo de vida de Angular
El comportamiento de ciclo de vida de un componente Angular pasa por diferentes etapas que podemos ver en el esquema que mostramos a continuaci贸n:
Es importante tenerlo claro para saber que m茅todos podemos utilizar para realizar operaciones con el componente.
Carpetas creadas por Angular
Al crear una aplicaci贸n Angular, tendremos los siguientes directorios:
- node_modules: Todos los m贸dulos de librer铆as usadas por el proyecto.
- \src\app: Contiene todo el c贸digo asociado al proyecto.
- \src\assets: Normalmente la carpeta usada para los recursos.
- \src\environments: Aqu铆 ir谩n los ficheros relacionados con los entornos de desarrollos.
Otros ficheros importantes de un proyecto de Angular
Otros archivos que debemos tener en cuenta dentro del proyecto son:
- angular.json: Configuraci贸n del propio CLI. La madre de todos los configuradores
- package.json: Dependencias de librer铆as y scripts
Estructura de m贸dulos
Existe m煤ltiples consensos al respecto de como estructurar un proyecto en Angular, pero al final, depende de los requisitos del proyecto. Una sugerencia de como hacerlo es la siguiente:
- src\app
- core /* Componentes y utilidades comunes */
- header /* Estructura del header */
- footer /* Estructura del footer */
- domain1 /* M贸dulo con los componentes del dominio1 */
- services /* Servicios con operaciones del dominio1 */
- models /* Modelos de datos del dominio1 */
- component1 /* Componente1 del dominio1 */
- componentX /* ComponenteX del dominio1 */
- domainX /* As铆 para el resto de dominios de la aplicaci贸n */
Recordar, que esto es una sugerencia para una estructura de carpetas y componentes. No existe un estandar.
ATENCI脫N: Componentes gen茅ricos
Debemos tener en cuenta que a la hora de programar un componente core, lo ideal es pensar que sea un componente plug & play, es decir que si lo copias y lo llevas a otro proyecto funcione sin la necesidad de adaptarlo.
Buenas pr谩cticas
A continuaci贸n veremos un listado de buenas pr谩cticas de Angular y de c贸digo limpio que deber铆amos intentar seguir en nuestro desarrollo.
Estructura de archivos
Antes de empezar con un proyecto lo ideal, es pararse y pensar en los requerimientos de una buena estructura, en un futuro lo agradecer谩s.
Nombres claros
Utilizar la S de los principios S.O.L.I.D para los nombres de variables, m茅todos y dem谩s c贸digo.
El efecto que produce este principio son clases con nombres muy descriptivos y por tanto largos.
Tambi茅n se recomienta utilizar kebab-case para los nombres de ficheros. Ej. hero-button.component.ts
Organiza tu c贸digo
Intenta organizar tu c贸digo fuente:
- Lo m谩s importante debe ir arriba.
- Primero propiedades, despu茅s m茅todos.
- Un Item para un archivo: cada archivo deber铆a contener solamente un componente, al igual que los servicios.
- Solo una responsabilidad: Cada clase o modulo deber铆a tener solamente una responsabilidad.
- El nombre correcto: las propiedades y m茅todos deber铆an usar el sistema de camel case (ej: getUserByName), al contrario, las clases (componentes, servicios, etc) deben usar upper camel case (ej: UserComponent).
- Los componentes y servicios deben tener su respectivo sufijo: UserComponent, UserService.
- Imports: los archivos externos van primero.
Usar linters Prettier & ESLint
Un linter es una herramienta que nos ayuda a seguir las buenas pr谩cticas o gu铆as de estilo de nuestro c贸digo fuente. En este caso, para JavaScript, proveeremos de unos muy famosos. Una de las m谩s famosas es la combinaci贸n de Angular app to ESLint with Prettier, AirBnB Styleguide Recordar que a帽adir este tipo de configuraci贸n es opcional, pero necesaria para tener un buen c贸digo de calidad.
Git Hooks
Los Git Hooks son scripts de shell que se ejecutan autom谩ticamente antes o despu茅s de que Git ejecute un comando importante como Commit o Push. Para hacer uso de el es tan sencillo como:
npm install husky --save-dev
Y a帽adir en el fichero lo siguiente:
// package.json
{
"husky": {
"hooks": {
"pre-commit": "npm test",
"pre-push": "npm test",
"...": "..."
}
}
}
Usar husky para el preformateo de c贸digo antes de subirlo
Es una buena pr谩ctica que todo el equipo use el mismo est谩ndar de formateo de codigo, con husky se puede solucionar.
Utilizar Banana in the Box
Como el nombre sugiere banana in the box se debe a la forma que tiene lo siguiente: [{}] Esto es una forma muy sencilla de trabajar los cambios en la forma de Two ways binding. Es decir, el padre informa de un valor u objeto y el hijo lo manipula y actualiza el estado/valor al padre inmediatamente. La forma de implementarlo es sencillo
Padre: HTML:
<my-input [(text)]="text"></my-input>
Hijo
@Input() value: string;
@Output() valueChange = new EventEmitter<string>();
updateValue(value){
this.value = value;
this.valueChange.emit(value);
}
Prefijo Change
Destacar que el prefijo 'Change' es necesario incluirlo en el Hijo para que funcione
Correcto uso de los servicios
Una buena practica es aconsejable no declarar los servicios en el provides, sino usar un decorador que forma parte de las ultimas versiones de Angular
@Injectable({
providedIn: 'root',
})
export class HeroService {
constructor() { }
}
Lazy Load
Lazy Load es un patr贸n de dise帽o que consiste en retrasar la carga o inicializaci贸n
desde el app-routing.module.ts o desde app.routes.ts si estamos en Angular 17+
A帽adiremos un codigo parecido a este
// Para cargar modulos
{
path: 'customers',
loadChildren: () => import('./customers/customers.module').then(m => m.CustomersModule)
},
// Para cargar standalone components
{
path: 'customers',
loadComponent: () => import('./customers/customers.component').then(m => m.CustomersComponent)
},
Con esto veremos que el m贸dulo o componente se cargar谩 seg煤n se necesite.