Hoja de ruta angular / Хабр
Pocas personas lo saben, pero el equipo Angular tiene hoja de rutaque describe las principales metas y objetivos que los desarrolladores se fijan. La hoja de ruta tiene como objetivo brindar a todos los usuarios del marco una comprensión del futuro que el equipo está definiendo ahora, así como también proporcionar planes para versiones futuras para mejorar la experiencia del usuario de otros desarrolladores, es decir, describe la dirección de desarrollo de Angular. .
Por el momento, el equipo de Angular se enfrenta a dos tareas principales:
Mejorar la experiencia de desarrollo;
Mejorar el rendimiento.
Pero antes de pasar a la implementación de estos planes, vale la pena considerar lo que ya ha sido implementado por el equipo de Angular y gracias a lo cual el marco ha mejorado.
¿Qué has logrado?
Transición a ESLint, ya que TSLint ahora está en desuso, manteniendo al mismo tiempo la compatibilidad con versiones anteriores;
Depuración de errores mejorada con mensajes más informativos;
Optimizar la velocidad de compilación y reducir el tamaño del paquete usando Webpack;
Fin del soporte para IE11;
Ahora IVY en lugar de View Engine;
Desarrollo de mecanografía fuerte.
@angular/forms;Simplificación del modelo mental Angular con la adición de componentes independientes y NgModules opcionales;
Documentación mejorada;
Rendimiento de imagen mejorado;
Hidratación + SSR;
Nuevo flujo de control;
La aparición de angular.dev;
Vistas aplazables;
y mucho, mucho más.
Experiencia del desarrollador
Señales angulares
Signals replantea el modelo reactivo de Angular al inyectar primitivas de datos como lo esencial reactividad. La planificación inicial dio lugar a cientos de debates y sesiones de retroalimentación, estudios de experiencia de usuario y una serie de RFC que recibieron más de 1000 comentarios.
Como parte del lanzamiento v17, la biblioteca Angular Signals pasó de una versión preliminar para desarrolladores a una versión estable, y en v18 ya es posible usar algunas de ellas en desarrollo. Se espera que continúen los comentarios de los desarrolladores, después de lo cual la API pasará al modo estable y se integrará más profundamente en el mecanismo de detección de cambios de Angular.
Puedes leer más sobre las señales aquí.
Angular sin Zone.js
v18 introdujo soporte experimental para Angular sin zona.js. Esto permite a los desarrolladores no incluir Zone.js en su paquete, lo que mejora el rendimiento, la depuración y la interoperabilidad con otras bibliotecas. Como parte del lanzamiento inicial, este cambio también se implementó en Angular CDK y Angular Material.
Variables locales en plantillas
Las variables locales en las plantillas son una de las características más intrigantes del rastreador de problemas de Angular. En el segundo trimestre de 2024, el equipo de Angular comenzó el diseño inicial y la creación de prototipos. Se deberían esperar actualizaciones de esta funcionalidad en un futuro próximo.
Nuevas primitivas CDK
También estamos trabajando en nuevas primitivas CDK para facilitar la creación de componentes personalizados basados en los patrones de diseño WAI-ARIA para listas desplegables. Angular v14 introdujo primitivas de diálogo y menú estables como parte de este proyecto, y v15 introdujo Listbox.
Accesibilidad de componentes angulares
Los componentes de Angular Material se evalúan según estándares de accesibilidad como WCAG, y el equipo de Angular trabaja para resolver cualquier problema que surja en este proceso.
Modernización de herramientas de prueba unitaria con ng test
En v12, el proceso de prueba de un extremo a otro de Angular se revisó y Protractor se reemplazó por alternativas modernas como Cypress, Nightwatch y Webdriver.io. Como parte de esta iniciativa, se avecinan cambios en ng test para modernizar el proceso de prueba unitaria de Angular. En el segundo trimestre de 2023, el equipo de Angular introdujo soporte experimental para Jest y anunció la transición de Karma a Web Test Runner.
Optimización de las importaciones con Language Service
Angular Language Service importa componentes y directivas en aplicaciones con Standalone y NgModule. Además, para crear paquetes de aplicaciones más pequeños, se espera que Angular Language Service también ofrezca la eliminación automática de importaciones no utilizadas.
¿Qué pasa con el rendimiento?
Hidratación parcial
La versión 17 eliminó la hidratación de la vista previa para desarrolladores y desde entonces ha visto constantemente una mejora del 40 al 50 % en LCP. Se ha iniciado la creación de prototipos de hidratación parcial, cuyo soporte experimental se espera para 2024.
Repetición del evento
La reproducción de eventos brinda la posibilidad de repetir eventos personalizados (como un clic) que ocurren en la página antes de que se complete la hidratación. Una vez que esto suceda, todos los eventos de usuario capturados se repetirán y se ejecutarán los controladores correspondientes. Esta característica se introdujo en la versión 18 y depende de la primitiva de envío de eventos (anteriormente conocida como jsaction) que se ejecuta en Google.com. Próximamente está previsto trasladar esta modificación a la sección estable.
Configuración de rutas del servidor
También estamos trabajando para hacer más ergonómica la configuración de rutas en el servidor. El equipo de Angular quiere facilitar la declaración de qué rutas deben representarse en el servidor, en el prerenderizado o en el lado del cliente.
Planes futuros
Esta sección trata exclusivamente de investigaciones y prototipos de futuros desarrollos. Numerosos RFC, priorización y rápidos cambios en las tecnologías web afectan directamente el destino futuro de estas funciones.
Señales de depuración en Angular DevTools
A medida que las señales se vuelvan más comunes en Angular, el equipo de Angular también trabajará para mejorar las herramientas para depurarlas. La prioridad es la interfaz de usuario para probar y depurar componentes basados en señales.
HMR (recarga del módulo en caliente) mejorado
Actualmente, Angular CLI admite HMR usando el comando ng serve --hmr. Básicamente, esto básicamente da como resultado volver a renderizar la aplicación Angular desde cero, lo cual es mejor que recargar la página por completo, pero ciertamente se puede mejorar. Lo más importante es que la estrategia aquí debería ser optimizar el tiempo de ejecución de cualquier cambio dependiendo de la frecuencia de ese tipo de cambio. En el futuro, el equipo de Angular explorará una serie de oportunidades para mejorar HMR, que incluyen:
Procese rápidamente cambios solo en CSS y aplíquelos a todos los componentes existentes en la página.
Procese rápidamente los cambios solo en las plantillas de Angular y aplíquelos a todos los componentes existentes en la página.
Transmisión de RSS
En las últimas versiones, se ha trabajado para hacer que el renderizado del lado del servidor de Angular sea más confiable. La prioridad es estudiar la representación del servidor de transmisión para aplicaciones sin zona.js; esta es una técnica en la que las páginas HTML se representan en el servidor y se envían al cliente en partes (transmisiones) a medida que está listo. Esto permite un primer tiempo de renderizado (FCP) más rápido porque el cliente comienza a renderizar el contenido sin esperar a que toda la página se cargue por completo. Este enfoque mejora el rendimiento y la experiencia del usuario, especialmente en conexiones complejas o lentas.
Mejoras en el formato de creación
Según los resultados de las encuestas a desarrolladores, se observaron oportunidades para mejorar la ergonomía del formato de creación de componentes. El primer paso en este proceso es recopilar requisitos y profundizar en el espacio del problema para preparar un RFC.
Admite arrastrar y soltar en dos ejes
Como parte de este proyecto, el equipo de Angular quiere implementar soporte para orientación de ejes mixtos para arrastrar y soltar en Angular CDK. Esta es una de las funciones más solicitadas en el rastreador de problemas de Angular.
Evaluación del soporte de Nitro en Angular CLI
Nitro es un marco del lado del servidor para crear aplicaciones web rápidas utilizando renderizado de servidor genérico (SSR) y generación estática (SSG). Nitro está diseñado para optimizar el rendimiento del servidor y resuelve los siguientes problemas: aceleración de la representación del servidor, facilidad de integración con varios servicios, optimización del rendimiento de la aplicación gracias al almacenamiento en caché mejorado. Más adelante, el equipo de Angular evaluará cómo encaja Nitro en el modelo de renderizado del lado del servidor de Angular.
