Una actualización sobre los componentes independientes
Tags: angular, spanish, programming, webdev
Published: 2022-05-14 00:29:36

(¡y directivas y pipes!)


> Artículo original de Angular Blog por Alex Rickabaugh en inglés [aquí](https://medium.com/r/?url=https%3A%2F%2Fblog.angular.io%2Fan-update-on-standalone-components-ea53b4d55214):

Durante el artículo encontrarás la RFC(Request for Comments) o Solicitud de comentarios, Carga diferida se refiere (lazily) o lazy loading.

Hace unos meses se [publicó el primer RFC](https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Fangular%2Fangular%2Fdiscussions%2F43784) relacionado con un proyecto conocido como "componentes independientes". Este proyecto tiene un objetivo ambicioso: reducir el modelo estándar y hacer que Angular sea más fácil de usar y aprender al hacer posible la creación de componentes y aplicaciones sin NgModules.

Unas  semanas, después, se construyo sobre esa base con un segundo RFC que analiza cómo los componentes independientes se integrarán en el resto del marco Angular. En esta publicación, compartiremos una actualización del proyecto, algunas lecciones aprendidas hasta ahora y lo que los desarrolladores pueden esperar en el futuro cercano.

## ¿Por qué componentes independientes?, ¿Qué tiene de malo los NgModules?

Los componentes independientes ayudarán a:

- Reducir el modelo estándar en muchas aplicaciones, especialmente para aquellas que ya utilizan patrones arquitectónicos como el patrón de módulo angular de componente único (SCAM). **Single Component Angular Module**

- Facilitar el aprendizaje de Angular eliminando el concepto NgModule de la curva de aprendizaje crítica de los desarrolladores nuevos en Angular

- Permitir ofrecer nuevas API y más optimizadas para casos de uso comunes

Un requisito común en una aplicación es cargar de forma diferida una ruta específica. Lograr esto hoy es bastante detallado. Para cargar de forma diferida una ruta a `LazyPageComponent`, por ejemplo:
 
{% gist https://gist.github.com/AntonioCardenas/6f4592b7404a02a3fe0ada9cc4729e50 %}

Esto es mucho código para escribir y entender. También es demasiado fácil cometer errores sutiles. Por ejemplo, si olvida importar `LazyPageModule` a `LazyPageRoutingModule`, es posible que esta ruta no funcione en tiempo de ejecución si a `LazyPageComponent` le faltan dependencias.

Con las nuevas API que aprovechan las garantías proporcionadas por los componentes independientes, lo anterior se puede reducir a:

{% gist https://gist.github.com/AntonioCardenas/d538c116b948087c43bb2589fcee0916 %}

Para obtener más detalles sobre la API `loadComponent` propuesta para la carga diferida de componentes independientes individuales, obtenga más información en el nuevo RFC.

## ¿Qué hay en el segundo RFC?

En los últimos meses, hemos centrado nuestros esfuerzos en la cuestión de cómo los componentes independientes encajan en el resto de Angular y cómo se pueden usar para lograr casos de uso específicos sin necesidad de recurrir a NgModules. El segundo RFC propone nuevas API que se integran con componentes independientes para admitir casos de uso importantes que anteriormente requerían NgModules:

- Hacer [Bootstrapping](https://es.wikipedia.org/wiki/Bootstrapping_(inform%C3%A1tica)) de una aplicación

- Cargar diferidamente componentes y/o rutas adicionales a través del enrutador

- Crear instancias dinámicamente de componentes en tiempo de ejecución

Además, el RFC cubre otras API relacionadas con el objetivo más amplio de reducir la necesidad de escribir NgModules, que incluyen:
Uso de NgModules existentes (como los de las bibliotecas) en las API existentes
Proporcionar lógica de inicialización en varios contextos, previamente soportada por NgModules

## ¿Qué desafíos hemos encontrado?

El tamaño del código siempre es una consideración importante al agregar cualquier característica nueva a Angular, incluido el proyecto independiente. Pasamos mucho tiempo pensando en el impacto que tendrán las nuevas características en los tamaños de los paquetes y cómo minimizar ese impacto en casos comunes. A menudo, estas consideraciones van en ambos sentidos: las aplicaciones existentes que aún utilizan API más antiguas no deberían necesitar enviar código asociado con las nuevas, pero los usuarios de API más nuevas tampoco deberían necesitar enviar código asociado con las más antiguas.
 
Por ejemplo, las aplicaciones que emplean la nueva API de arranque independiente propuesta no deberían necesitar enviar el código asociado con el sistema de arranque anterior basado en NgModule. Hacer que esto funcione de manera óptima es un desafío, ya que las API más antiguas no necesariamente se han diseñado teniendo en cuenta estas consideraciones.

## ¿Cómo cambiará esto la guía de estilo de Angular?

A corto plazo, no planeamos actualizar la guía de estilo de Angular ni la aplicación predeterminada de `ng new`. Los componentes independientes estarán disponibles por primera vez como una función opcional.
A más largo plazo, recopilaremos comentarios de los desarrolladores de nuestra comunidad a medida que usen las nuevas API y usaremos esos comentarios para revisar tanto la guía de estilo como la experiencia `ng new`.

## ¿Qué tan avanzado está el proyecto? ¿Cuándo puedo utilizar componentes independientes?
La implementación de la funcionalidad central de los componentes independientes ya está en marcha y hemos comenzado a crear prototipos de las API propuestas que se describen [en el nuevo RFC](https://github.com/angular/angular/discussions/45554). A medida que recibamos comentarios, perfeccionaremos esas implementaciones.

Dado que toda la funcionalidad de los componentes independientes y las API asociadas son opcionales y no se rompen, los componentes independientes no tienen que esperar a una versión principal; podremos lanzar esta nueva función emocionante en una próxima versión secundaria de Angular tan pronto como esté listo. ¡Así que permanezca atento a medida que continuamos progresando y asegúrese de [leer el RFC](https://github.com/angular/angular/discussions/45554)!