Una guía completa de Angular componentes independientes

Si hay un marco que no deja piedra sin remover cuando se trata de cambiar y mejorar el proceso de desarrollo, es Angular. Con la última versión Angular 16.0.0, ahora hay algunos avances importantes en cosas como las herramientas, la representación del lado del servidor y la reactividad. Y para mí, la introducción de Angular API independiente es una de las mayores mejoras en la última versión que aporta toneladas de ventajas a la comunidad de desarrolladores. La nueva función llamada Esquemas para componentes independientes, en particular, parece estar renovando nuestra capacidad para crear elementos y bibliotecas de interfaz de usuario reutilizables y, al mismo tiempo, eliminar los módulos repetitivos.

¿Y eso no está cambiando el juego significativamente?

Pero profundicemos en los componentes Angular independientes (SAC) para comprender mejor todo el entusiasmo que los rodea, así como cómo funcionan exactamente, cómo crearlos, qué ha cambiado desde Angular 14, cuando se presentó por primera vez el concepto de componentes independientes, etc.

¿Qué es un componente independiente en Angular o es un adiós a NgModules?

La forma más corta de definirlos es que los componentes independientes nos permiten construir aplicaciones Angular sin usar módulos. Dado que no están vinculados a ningún módulo específico, se pueden utilizar en cualquier parte de la aplicación. Esto significa que las clases independientes no necesitan ser declaradas en un NgModule, por lo que tenemos menos código repetitivo.

Básicamente, los componentes independientes no son obligatorios. Recomendado sí, pero no obligatorio. Sin embargo, Angular recomienda utilizar siempre componentes independientes, al menos para los nuevos componentes que cree. Simplemente, son más agitables y menos calderas. Puede mezclar componentes y módulos independientes. Estoy de acuerdo en que podemos usar componentes independientes en lugar de módulos, al menos en el futuro, pero si decides dejar el resto de tu componente modularizado, no es una mala decisión.

En Angular 14, se introdujo la idea de componentes independientes junto con API independientes, una vista previa para desarrolladores en ese momento. Se referían a un tipo de componente que no formaba parte de ningún módulo y que podía utilizarse de forma independiente sin estar anidado dentro de otros componentes. Por el contrario, cuando querías crear un componente antes de eso, normalmente tenías que pasarlo dentro de la matriz de declaración del módulo.

Luego, el concepto comenzó a cambiar y el proceso de desarrollo evolucionó gradualmente.

La documentación oficial Angular, por ejemplo, estipula que "los componentes, directivas y tuberías independientes tienen como objetivo optimizar la experiencia de creación al reducir la necesidad de NgModule. Las aplicaciones existentes pueden adoptar opcional e incrementalmente el nuevo estilo independiente sin ningún cambio importante".

En otras palabras, aquí tenemos una simplificación.

Ahora, con Angular 16, obtenemos oficialmente la función Esquemas para componentes independientes y componentes independientes que están diseñados para ser autónomos, modulares y reutilizables. Pero, ¿por qué utilizar componentes independientes en Angular? Si bien no están reemplazando completamente el uso de NgModules, nos permiten utilizar una nueva forma de crear código modular y reutilizable. A lo largo del camino, incluso logramos una mejor capacidad de mantenimiento y prueba para nuestras aplicaciones Angular, además de una estructura de proyecto que permanece intacta.

¡Esta es una gran alternativa!

Pero, de nuevo, los componentes independientes de Angular no son un reemplazo, sino una alternativa a los NgModules.

¿Qué otros Angular beneficios de los componentes independientes existen?

Aquí hay algunas razones más para usar componentes independientes en Angular:

• Son la solución liviana que puede eliminar efectivamente la clase y todos los demás excesos que la acompañan.
• Capacidad para adoptar una API más funcional en comparación con la API basada en clases mucho más pesada que solía tener.
• Ahora podemos cargar el componente directamente sin un NgModule.
• Vienen con la capacidad de encapsular la funcionalidad y promover la reutilización del código en toda la aplicación sin causar posibles errores con otros componentes.
• Ya no hay necesidad de un AppModule, ya que podemos arrancar la aplicación con un componente.
• El enrutamiento en componentes de Angular independientes ahora es más agitable para que podamos apuntar directamente a un componente enrutado o a una configuración de ruta.
• Pueden importar fácilmente otros componentes independientes, directivas, tuberías y NgModules existentes.
• Cada componente tiene su propio archivo (plantilla, estilos, código TypeScript), lo que da como resultado una estructura de código mucho mejor.
• Diseña componentes teniendo en cuenta la reutilización y puede añadir fácilmente nuevas características o ampliar las funcionalidades existentes.
• Puede escribir pruebas unitarias específicamente para cada componente Angular independiente.

¿Cómo crear un componente independiente en Angular?

1. Creating them

Crear su primer componente independiente es muy fácil y se realiza mediante el uso de la marca –-standalone. Pero primero, asegúrate de estar en Angular 16.

        2. Using them

Puede utilizar un componente independiente de dos maneras:

• En otro componente independiente, simplemente pasándolo a la propiedad imports del mismo componente independiente.
• O dentro de un módulo pasándolo a la matriz de importaciones.

Uso de componentes independientes con Ignite UI for Angular

A partir de Angular 16 y Ignite UI for Angular 16.0, ahora puede simplemente agregar las importaciones que necesita su componente independiente en la propiedad imports. En el siguiente ejemplo IGX_GRID_DIRECTIVES se puede utilizar para importar todos los componentes y directivas relacionados con la red. A continuación, se explica cómo crear y utilizar un componente independiente en Angular con Ignite UI.

import {IGX_GRID_DIRECTIVES} from 'igniteui-angular';

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IGX_GRID_DIRECTIVES, AsyncPipe] 
})

También puede importar todos los componentes utilizados por su componente independiente individualmente. A continuación se muestra un ejemplo con IgxGridComponent e IgxColumnComponent, cuando otro componente solo usa estos dos.

import {IgxGridComponent, IgxColumnComponent} from 'igniteui-angular'; 

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IgxGridComponent, IgxColumnComponent, AsyncPipe] 
})

Todos los componentes Ignite UI for Angular ahora se exportan como componentes independientes. La biblioteca sigue exportando NgModules, que se han conservado por compatibilidad con versiones anteriores, pero ya no declaran ninguno de los componentes Ignite UI for Angular.

En su lugar, simplemente importan y exportan los componentes independientes. Es importante tener en cuenta que los componentes independientes aún se encuentran en una etapa de vista previa. Es posible que algunas exportaciones de directivas de utilidad cambien en el futuro y que falten en la documentación de la versión inicial, de ahí el estado de vista previa de la característica.

¿Cuáles son algunas de las mejores prácticas para Angular componentes independientes?

Al trabajar con Angular componentes independientes, puede seguir varias prácticas recomendadas para garantizar un código limpio, fácil de mantener y reutilizable, así como proyectos de siguiente nivel.

• Considere el tamaño de su proyecto y código

Como primer paso, ten en cuenta el tamaño del proyecto y cómo está organizado el código. Es posible que lea que no hay cambios importantes relacionados con la migración de componentes normales a independientes si simplemente cambia todos sus componentes a independientes. Sin embargo, puedo garantizarle que introducirá algunos errores importantes en su aplicación. Sin embargo, es posible que no desee migrar todo el código a componentes independientes. Agrupar componentes en un módulo y exportar solo algunos de ellos es un patrón perfectamente fino. ¿Cómo trasladaría esto a componentes independientes? En lugar de un ngModule, tendrá que configurar una API usando barrelfiles, mientras protege los componentes privados con reglas de linting. En este caso, los componentes independientes no necesariamente hacen que un proyecto sea más fácil de administrar.

Por lo tanto, si el tamaño de su proyecto es de mediano a grande, mi consejo es comenzar esta migración con bastante lentitud y simplemente migrar todo el SCAM (Single Component Angular Module). Con SCAM, un NgModule declara solo un componente. Debido a que ya están separados, puede acostumbrarse a crear y trabajar con componentes independientes a partir de ese momento.

• Migración de tuberías y directivas

Otra buena práctica es migrar todas las canalizaciones y directivas a componentes independientes. De esta manera, puede simplificar y reducir algunos de los módulos.

• Ajustar y mejorar continuamente el código

Después de eso, dese a sí mismo y a su equipo tiempo para ajustar y mejorar continuamente su base de código durante una refactorización de código regular. Porque en un proyecto de tamaño empresarial, la migración a componentes independientes será una gran tarea. Al hacer esto, puede asegurarse de que no se introduzcan regresiones, mientras que todos los cambios están bien probados y revisados por sus colegas.

En conclusión...

El argumento de que los componentes independientes eliminan una gran cantidad de texto repetitivo para mí es solo parcialmente cierto. Ya no es necesario crear un módulo. En su lugar, casi todos los componentes necesitarán importar al menos CommomModule para que Angular funcione como se espera. Para casos más complejos, también habrá que importar una lista bastante larga de otros módulos y componentes. En algunos casos, entonces, esto conduce a declaraciones de importación realmente largas y cuando abre un archivo, debe desplazarse una página completa para ver realmente el código del componente en sí.

No hay una respuesta fácil a este problema. Se han hecho sugerencias para cortar el CommonModule para que solo tenga que importar lo que se necesita, pero esto podría conducir fácilmente a una larga lista de importaciones. Una alternativa podría ser que ciertas características, como la directiva *ngIf, se importen de forma predeterminada. Actualmente, no hay planes concretos por parte del equipo de Angular en esta dirección.

Por lo tanto, no hay nada de malo en permitir que ambos conceptos vivan juntos en la base de código de su proyecto durante algún tiempo y ver cómo su proyecto continuará evolucionando y qué exactamente funcionará mejor.