Has visto una librería sin opiniones (React), un framework progresivo que se adopta por capas (Vue) y, antes de los dos, tu propia aplicación en JavaScript puro donde todas las decisiones eran tuyas. Angular está en el otro extremo del eje que 10-01 llamó «librería frente a framework»: es una plataforma completa, con enrutador, cliente HTTP, sistema de formularios, inyección de dependencias, entorno de pruebas, generador de código y renderizado en servidor incluidos y mantenidos por el mismo equipo. Y con TypeScript no como opción sino como requisito de hecho. Eso lo hace el más costoso de aprender de los tres y, a la vez, el más previsible: dos proyectos Angular de empresas distintas se parecen mucho más entre sí que dos proyectos React. En esta lección verás qué significa «con opiniones» cuando se lleva hasta el final; lo mínimo de TypeScript para leer el código —tipos, interfaces y decoradores—, remitiendo a 11-07 para aprenderlo en serio; la CLI y la estructura de un proyecto; los componentes independientes (standalone) con sus imports, que hoy son la forma recomendada; las cuatro formas de enlace de datos y la sintaxis de control de flujo actual (@if, @for con su track obligatorio —el mismo data-id de siempre—, @switch y @defer); las señales (signal, computed, effect, y las entradas y salidas basadas en señales) como modelo de reactividad actual de Angular, comparadas con los ref y computed de Vue, con una mención de Zone.js y de la tendencia zoneless; la inyección de dependencias, que es la pieza que más diferencia a Angular y que ya practicaste sin saberlo en 08-04; HttpClient y lo justo de RxJS —qué es un flujo, subscribe, pipe, el async de la plantilla y por qué hay que darse de baja— aplicado a tu listarTareas de 07-02; el enrutador con carga perezosa, retomando 09-05; los formularios reactivos con validadores que reutilizan tus reglas R1–R10; las pruebas con TestBed y una nota sobre SSR. Y al final, la misma lista de tareas con filtro, por cuarta vez.

1. Angular como plataforma completa
2. Qué significa «con opiniones» llevado hasta el final
3. TypeScript: lo mínimo para leer esta lección
4. Decoradores: qué son y por qué los usa Angular
5. La CLI y la estructura de un proyecto
6. Componentes independientes (standalone)
7. Plantilla y estilos: las tres formas de escribirlos
8. Enlace de datos en sus cuatro formas
9. La sintaxis de control de flujo actual
10. @for y su track obligatorio
11. @defer: carga perezosa declarativa
12. Señales: signal, computed y effect
13. Entradas y salidas basadas en señales
14. Zone.js, la detección de cambios y la tendencia zoneless
15. Señales de Angular frente a ref de Vue
16. Inyección de dependencias: servicios e inject()
17. Por qué la inyección de dependencias diferencia a Angular
18. El parecido con lo que hiciste en 08-04
19. HttpClient y RxJS: lo justo
20. El async de la plantilla y por qué hay que darse de baja
21. Cuándo señales y cuándo observables
22. El enrutador con carga perezosa
23. Formularios reactivos frente a formularios de plantilla
24. Validadores con las reglas R1–R10
25. Pruebas con TestBed
26. Una nota sobre SSR
27. Nómada Tareas en Angular: la lista completa
28. Comparación con las tres versiones anteriores
29. Errores Comunes y Consejos
30. Ejercicios
31. Conclusión

La diferencia empieza en el inventario. Esto viene incluido, es oficial y se actualiza a la vez:

Esa última fila de ng update merece atención porque es una consecuencia poco comentada de tener todo bajo el mismo techo: cuando Angular cambia un API, publica migraciones automáticas que reescriben tu código. Actualizar un proyecto Angular grande suele ser ejecutar un comando y revisar el resultado. En un proyecto React con veinte dependencias de terceros, cada una se actualiza a su ritmo y las incompatibilidades son tuyas. Es una ventaja real de la integración vertical, y es la contrapartida directa del coste 5 de 10-01, la rotación del ecosistema.

En la práctica, «con opiniones» significa cinco cosas concretas:

1. No eliges herramientas, eliges Angular. No hay decisión que tomar sobre enrutador, cliente HTTP o sistema de formularios. Eso elimina la fatiga de decisión y elimina también la posibilidad de usar algo mejor para tu caso.
2. La estructura del proyecto viene dada. ng generate component tarjeta-tarea crea cuatro ficheros con nombres, ubicación y contenido predecibles. Todos los proyectos se parecen.
3. Hay una forma correcta de hacer cada cosa, documentada, y el resto de la comunidad la sigue.
4. La verbosidad es deliberada. Angular prefiere explícito y largo antes que conciso y mágico. Verás más líneas para hacer lo mismo, y esas líneas dicen exactamente qué ocurre.
5. La curva es más empinada al principio y más plana después. Hay más conceptos que aprender antes de ser productivo (inyección de dependencias, decoradores, observables), y menos sorpresas una vez aprendidos.

El perfil donde Angular brilla es reconocible: aplicaciones grandes, de larga vida, con equipos numerosos y rotación de personal, típicamente internas o corporativas. Y el perfil donde estorba también: un prototipo, un widget, una web pequeña, una persona sola con prisa.

Angular está escrito en TypeScript y su documentación, sus ejemplos y sus herramientas lo dan por hecho. Se puede usar con JavaScript, pero nadie lo hace y el ecosistema no lo acompaña. Así que necesitas lo mínimo para leer el código. Esto no es un curso de TypeScript: en 11-07 verás qué es, por qué ha ganado y cómo aprenderlo en serio. Aquí van cuatro ideas.

TypeScript es JavaScript con anotaciones de tipo. Todo JavaScript válido es TypeScript válido. Las anotaciones se comprueban al compilar y desaparecen del resultado: en el navegador se ejecuta JavaScript normal.

Las interfaces describen la forma de un objeto. Son la documentación que el compilador comprueba:

Fíjate en Prioridad. Es un tipo de unión de literales, y hace algo que ningún comentario consigue: si escribes prioridad: 'urgente', el compilador lo rechaza antes de ejecutar nada. Las reglas R1–R10 que llevas todo el curso comprobando a mano se convierten, en buena parte, en cosas que el compilador impide expresar.

Los genéricos son tipos con parámetros. Tarea[] es un array de tareas; Signal<number> es una señal que contiene un número; Observable<Tarea[]> es un flujo que emite arrays de tareas. Se leen como «X de Y».

Los modificadores de acceso son la versión de TypeScript de la encapsulación de 05-03:

Con un matiz que conviene saber: private de TypeScript desaparece al compilar y solo protege durante el desarrollo, mientras que los #campos de JavaScript de 05-03 son privados de verdad en tiempo de ejecución. Angular usa mayoritariamente private.

Los decoradores son la sintaxis con @ que verás por todas partes:

Un decorador es una función que recibe la clase y le añade metadatos. @Component({...}) no cambia el comportamiento de la clase: le adjunta información —cuál es su plantilla, qué selector usa, qué otros componentes importa— que Angular lee al compilar y al ejecutar.

La razón de que Angular los use es coherente con su filosofía: la configuración vive junto a lo que configura, de forma declarativa y legible. En React esa información está repartida entre el nombre del fichero, las importaciones y el JSX; en Angular está en un objeto explícito encima de la clase.

Para leer esta lección basta con entenderlos como «metadatos declarados encima de una clase». No necesitas escribir uno.

La CLI de Angular hace mucho más que crear proyectos:

ng generate component crea cuatro ficheros y los registra donde corresponda:

Ese cuarto fichero dice mucho sobre las opiniones de Angular: la prueba se genera con el componente, no se añade después si a alguien le apetece. Es la misma idea que 08-03 defendía, convertida en comportamiento por defecto de la herramienta.

Y la estructura general:

Compara con tu js/modelo/, js/datos/, js/vista/, js/util/. La separación es la misma que decidiste tú; la diferencia es que aquí viene dada y todo el mundo la usa igual.

Durante años, Angular organizaba todo en NgModule: un componente no existía hasta declararlo en un módulo, y los módulos importaban otros módulos. Era una capa de indirección que costaba explicar y que a menudo sobraba.

Hoy la forma recomendada son los componentes independientes, que declaran directamente qué necesitan:

Los elementos del decorador:

• selector es la etiqueta HTML con la que se usa: <app-filtro-responsable>. El prefijo app- es la convención para evitar colisiones con elementos nativos.
• template (o templateUrl) es la plantilla.
• styles (o styleUrls) son los estilos, con ámbito por defecto, como el scoped de Vue de 10-04 pero sin tener que pedirlo.
• imports —que aquí no hace falta porque no se usa ningún componente ni directiva externa— lista lo que la plantilla necesita.

Los componentes independientes son hoy el valor por defecto de la CLI. Verás mucho código antiguo con NgModule; sigue funcionando y hay migraciones automáticas, pero para código nuevo no es la forma recomendada.

Esto es una diferencia real con Vue, y va en las dos direcciones. Angular por defecto usa tres ficheros para un componente (lógica, plantilla, estilos), lo que aleja las partes; pero el ámbito de estilos viene activado sin pedirlo y las herramientas del editor navegan entre los tres sin fricción. Para componentes pequeños, la forma en línea deja algo muy parecido a un fichero .vue.

El ámbito de estilos se implementa con atributos únicos añadidos por el compilador, igual que en Vue. Se puede cambiar a Shadow DOM real con encapsulation: ViewEncapsulation.ShadowDom, o desactivarlo — cosa que casi nunca conviene.

Angular tiene una sintaxis muy explícita para distinguir la dirección del dato, y una vez aprendida se lee muy bien:

La mnemotecnia oficial es útil: los corchetes apuntan hacia dentro (el dato entra en el elemento), los paréntesis apuntan hacia fuera (el evento sale del elemento), y [()] —«caja de plátano en una caja»— hace las dos cosas.

Y [(ngModel)] es, como el v-model de Vue, puro azúcar:

Una propiedad que baja y un evento que sube. Otra vez el flujo unidireccional con un atajo encima. Aviso práctico: ngModel pertenece a FormsModule y hay que importarlo en el componente; y para formularios de cierta entidad, Angular recomienda los formularios reactivos del apartado 23, no ngModel.

Para clases y estilos hay formas específicas:

Durante años Angular usaba directivas estructurales con asterisco (*ngIf, *ngFor, ngSwitch). Hoy hay una sintaxis de bloques integrada en el compilador, que es la recomendada para código nuevo:

Cuatro ventajas sobre las directivas antiguas, todas prácticas:

1. No hace falta importar nada. *ngIf requería importar CommonModule o NgIf; olvidarlo producía un fallo silencioso en el que el contenido simplemente no aparecía.
2. Hay @else de verdad. Con *ngIf había que usar <ng-template> y referencias, que era considerablemente más incómodo.
3. @empty cubre el estado vacío sin un @if adicional. Es justo el caso que 06-06 te obligó a tratar aparte.
4. El compilador la entiende mejor y genera código más eficiente, además de mejores mensajes de error.

Compara las tres sintaxis para lo mismo:

Por cuarta vez en el módulo, el mismo concepto. Y en Angular es donde está mejor resuelto, porque track no es opcional:

Si escribes @for sin track, el código no compila. No es un aviso en la consola como en React ni una regla de ESLint como en Vue: es un error de compilación que impide construir el proyecto.

Esa decisión resume la filosofía de Angular. La identidad estable en las listas es tan importante —lo sabes desde 06-06, cuando reconciliar sin data-id te habría costado el foco, las transiciones y el estado interno— que el framework no te deja olvidarla. Es «con opiniones» en su forma más útil: la opinión te obliga a hacer lo correcto.

Las mismas tres reglas, con la misma trampa: track $index está permitido y es lo correcto solo si la lista nunca se reordena ni se filtra. Con un id disponible, se usa el id.

Angular ofrece además variables contextuales dentro del bloque:

Disponibles: $index, $first, $last, $even, $odd, $count.

Este bloque merece atención propia porque conecta directamente con 09-05 y porque no tiene equivalente tan integrado en los otros frameworks:

Lo que hace: el componente app-informe-carga y todas sus dependencias se separan en un trozo aparte durante la compilación, y solo se descargan cuando se cumple la condición. Los disparadores disponibles son on viewport, on interaction, on hover, on idle, on timer(…), on immediate, y when <expresión>, además de prefetch on … para precargar sin renderizar.

Compara con lo que escribiste en 09-05:

Y con el IntersectionObserver con rootMargin que también escribiste. @defer hace todo eso —la división del código, el disparador, el indicador con su retardo mínimo para evitar parpadeos, el hueco reservado que evita el CLS, y el manejo del fallo— de forma declarativa y comprobada por el compilador. Es exactamente el argumento de 10-01: no es que no supieras hacerlo; es que aquí lo escribes en ocho líneas de plantilla y no puedes olvidarte del estado de error.

Las señales son el modelo de reactividad actual de Angular, y su parecido con los ref de Vue no es casual: son la misma familia 2 de 10-01.

La diferencia sintáctica con Vue: donde Vue usa .value (una propiedad), Angular usa () (una llamada). El motivo es el mismo del apartado 12 de 10-04 —JavaScript no permite interceptar la lectura de una variable—, resuelto con otra herramienta: una función en lugar de un getter.

computed declara un derivado, con caché y dependencias automáticas:

Idéntico en semántica al computed de Vue: perezoso, cacheado, componible, con las dependencias descubiertas al leer. Y por tanto idéntico también a tu caché por versión de 09-02, con la invalidación automática.

effect ejecuta efectos secundarios cuando cambian sus dependencias:

Con la misma advertencia de useEffect y de watch: effect no es para derivar valores. Escribir en una señal desde dentro de un effect para calcular algo es el mismo antipatrón que has visto ya dos veces, y Angular lo desaconseja explícitamente (hasta el punto de que escribir señales dentro de un efecto requiere una opción especial).

Hay un detalle relevante sobre inmutabilidad. Una señal detecta el cambio comparando con Object.is, como React y no como Vue: no hay proxy que intercepte la escritura en una propiedad anidada.

Es decir: en Angular con señales, la inmutabilidad de 04-07 vuelve a ser obligatoria, igual que en React. Es un buen ejemplo de que las tres familias de 10-01 se cruzan: Angular tiene reactividad de grano fino con requisito de inmutabilidad; Vue tiene grano fino con mutación permitida; React tiene DOM virtual con inmutabilidad obligatoria.

La comunicación entre componentes usa input() y output(), que sustituyen a los decoradores @Input() y @Output() del Angular anterior:

Puntos importantes:

• input.required<Tarea>() declara una entrada obligatoria y tipada. Si el padre no la pasa, falla al compilar. Compáralo con las props de React, donde solo TypeScript lo detecta, o con defineProps de Vue, que valida en tiempo de ejecución en desarrollo.
• Una entrada es una señal. Se lee con tarea() y se puede usar directamente como dependencia de un computed. Eso significa que vencida se recalcula sola cuando el padre pasa otra tarea, sin nada parecido al array de dependencias.
• output<number>() declara un evento tipado. El padre lo escucha con (avanzar)="…".
• ETIQUETA se expone como propiedad porque las plantillas de Angular solo ven miembros de la clase, no las importaciones del módulo. Es una diferencia real con JSX (donde todo el ámbito del fichero está disponible) y con Vue (donde <script setup> expone todo automáticamente): en Angular hay que hacerlo explícito.

Para entender el Angular que verás en proyectos reales hace falta saber de dónde viene su reactividad.

Durante casi toda su historia, Angular no supo qué había cambiado: lo comprobaba todo. El mecanismo era Zone.js, una librería que parchea las APIs asíncronas del navegador —setTimeout, addEventListener, fetch, Promise— para avisar a Angular cada vez que ocurre algo. Al recibir el aviso, Angular recorre el árbol de componentes evaluando todas las expresiones de todas las plantillas y comparando los resultados con los anteriores.

Funciona, y es la razón de que Angular «simplemente actualice» cuando mutas una propiedad. Pero tiene tres costes: comprueba mucho más de lo necesario; Zone.js pesa y parchea APIs globales, lo cual complica la depuración y la interoperabilidad; y no da información de grano fino, así que hay que optimizar a mano con ChangeDetectionStrategy.OnPush.

Las señales cambian eso. Como una señal sabe exactamente qué expresiones la leyeron, Angular puede actualizar solo lo que depende de lo que cambió. Ese es el fundamento de la tendencia zoneless: aplicaciones donde toda la reactividad pasa por señales y Zone.js deja de hacer falta, con lo que desaparece del paquete y la detección de cambios pasa a ser dirigida por datos en lugar de por sondeo.

En la práctica, para escribir Angular moderno la regla es: usa señales para todo el estado. Si lo haces, el modelo mental es el mismo que el de Vue y no necesitas pensar en Zone.js. Pero al leer código existente te encontrarás propiedades normales de clase actualizándose solas: eso es Zone.js trabajando, y ahora sabes por qué.

Dos filas merecen comentario.

La de la inmutabilidad es la diferencia práctica más visible, y va acompañada de una compensación: como no hay proxy, las señales de Angular son más baratas y más previsibles; no hay que preguntarse si un objeto está envuelto ni si un Map es reactivo. A cambio, escribes el map inmutable de 04-07 en cada actualización.

La de desestructurar es una ventaja clara de las señales: como el valor se obtiene llamando a una función, pasar la señal a otro sitio nunca rompe nada. Todo el apartado 15 de 10-04 —los cuatro límites de la reactividad de Vue— simplemente no aplica aquí. Es un caso donde la sintaxis más incómoda (() en cada lectura) compra una propiedad valiosa.

Aquí está lo que de verdad diferencia a Angular. Los otros dos frameworks no tienen nada equivalente.

Un servicio es una clase con lógica que no pertenece a ningún componente: acceso a datos, estado compartido, reglas de negocio, registro de eventos.

Y su uso desde un componente:

Tres cosas que hay que entender de este código:

@Injectable({ providedIn: 'root' }) registra el servicio en el inyector raíz. Angular crea una sola instancia y se la da a todo el que la pida. Es un singleton, pero gestionado por el framework en lugar de por un módulo exportando un objeto.

inject(TareasService) pide la instancia. No hay new, no hay importación de una instancia concreta: se pide el tipo y el inyector decide qué dar. Esa indirección es la clave de todo lo que viene después.

El estado está en el servicio, no en el componente. El patrón _tareas privado escribible más tareas público de solo lectura (asReadonly()) es la encapsulación de 05-03 aplicada al estado: el servicio es el único que puede cambiarlo, y los componentes solo leen. Es exactamente la disciplina que tu clase Tablero imponía con #tareas y el getter que devolvía una copia.

La pregunta razonable es: ¿qué aporta pedir inject(TareasService) en lugar de importar una instancia?

Aporta que quien decide qué instancia se entrega no es quien la usa. Y de ahí salen cuatro capacidades:

1 · Sustituir en pruebas. Al probar el componente, se le da un servicio falso sin tocar el componente:

2 · Cambiar la implementación por entorno. El mismo componente usa un servicio contra la API real en producción y contra datos locales en desarrollo, decidido en la configuración.

3 · Ámbitos distintos. Un servicio puede ser único para toda la aplicación (providedIn: 'root'), o crearse una instancia por componente si se declara en sus providers. Eso permite, por ejemplo, un servicio de estado por cada panel abierto.

4 · Interceptores. HttpClient se puede envolver con interceptores que añaden cabeceras de autenticación, reintentan (tu conReintentos de 07-03), registran o gestionan errores, sin que ningún servicio ni componente se entere.

El coste, dicho claro: es un concepto más que aprender, y uno que no existe en React ni en Vue. Para una aplicación pequeña es ceremonia; para una grande con muchas capas y pruebas exhaustivas, es la pieza que mantiene el código desacoplado.

Y aquí está la conexión que hace que todo esto te resulte familiar. En 08-04 escribiste esto para poder probar tu repositorio:

Eso es inyección de dependencias. No la inventó Angular: es un patrón de diseño con décadas, y tú lo aplicaste por la razón correcta —para poder probar sin depender de localStorage—. Lo que hace Angular es dos cosas más:

1. Convertirla en la norma, no en algo que se hace cuando alguien se acuerda.
2. Automatizar el cableado: en tu versión, quien construye RepositorioLocal tiene que saber qué almacén pasarle, y ese conocimiento se propaga hacia arriba. Con un inyector, se declara una vez qué implementación corresponde a cada tipo y el framework lo resuelve en todo el árbol.

Si el patrón te pareció útil en 08-04 —y lo era, porque sin él aquellas pruebas habrían necesitado un navegador real—, Angular te lo da en toda la aplicación sin esfuerzo adicional.

HttpClient es el cliente HTTP incluido, y devuelve observables en lugar de promesas:

Lo mínimo de RxJS para leer esto, sin más:

Un observable es un flujo de valores en el tiempo. Una promesa produce un valor (o un fallo) y termina; un observable puede producir cero, uno o muchos, y puede no terminar nunca. Un clic de ratón es un flujo. Un WebSocket —tu CanalTablero de 07-04— es un flujo. Una petición HTTP es un flujo que emite un valor y termina, y por eso parece una promesa con sintaxis rara.

subscribe arranca el flujo. Un observable es perezoso: hasta que alguien se suscribe, no ocurre nada. Esta es la trampa número uno para quien viene de promesas: llamar a listarTareas() sin subscribe no hace ninguna petición. Una promesa, en cambio, empieza a ejecutarse en cuanto se crea.

pipe encadena operadores. Un operador transforma el flujo y devuelve otro flujo. Los que aparecen constantemente:

switchMap merece un ejemplo, porque resuelve elegantemente la condición de carrera de 10-02:

Ese switchMap es la respuesta canónica al problema que en React resolviste abortando a mano y en Vue con alLimpiar. Cuando llega un valor nuevo, se cancela la suscripción anterior —y con ella la petición HTTP— y se suscribe a la nueva. La carrera es imposible por construcción.

Y toSignal/toObservable son los puentes entre los dos mundos: convierten un observable en señal y viceversa. Son la herramienta que permite escribir la aplicación con señales y usar RxJS solo donde aporta.

En la plantilla, el pipe async se suscribe y se da de baja automáticamente:

Es la forma recomendada cuando se trabaja con observables en plantillas, precisamente porque elimina el problema de darse de baja.

Y ese problema es real. Un observable que no termina —un WebSocket, un flujo de eventos, un temporizador— mantiene viva su suscripción aunque el componente desaparezca. Es literalmente la fuga de memoria de 09-03: el manejador sigue en memoria, sigue procesando, y mantiene vivo el componente y todo su subárbol.

takeUntilDestroyed es tu destruir(), una vez más, con la llamada garantizada por el framework. Las tres formas correctas de gestionar la baja, por orden de preferencia: el pipe async en la plantilla, takeUntilDestroyed, y —si no hay más remedio— guardar la suscripción y llamar a unsubscribe() en ngOnDestroy.

Angular tiene ahora dos sistemas reactivos conviviendo, lo cual desconcierta. El criterio actual es razonablemente claro:

En la práctica, el Angular moderno tiende a: señales para casi todo el estado de la aplicación, RxJS para la capa de datos y las interacciones complejas, y toSignal en la frontera. Es un modelo con más piezas que Vue o React, y esa es una crítica legítima a la curva de aprendizaje de Angular — con la contrapartida de que RxJS resuelve problemas de coordinación asíncrona que en los otros frameworks se resuelven a mano o con librerías.

Ese loadComponent con import() dinámico es exactamente la división de código de 09-05, integrada en el enrutador: cada ruta se compila en su propio trozo y solo se descarga al navegar a ella. Es la fila «Angular trae división de código en el enrutador» que 09-05 anunciaba.

Y hay una pieza que en tu enrutador.js no tenías: las guardas. canActivate ejecuta una función antes de activar la ruta y puede impedir la navegación o redirigir:

En la plantilla, la navegación se hace con directivas:

routerLink genera un <a href> real —importante para la accesibilidad y el SEO— e intercepta el clic para navegar sin recargar, que es exactamente lo que hacía tu enrutador con la History API de 07-06.

Angular incluye dos sistemas, y esta es la comparación que decide cuál usar:

Los reactivos en acción:

Un validador es una función pura que recibe el control y devuelve null si es válido o un objeto de errores si no. Es decir: exactamente la forma de tus funciones de validación de 03-03, con otra firma.

Tres observaciones:

• Son funciones puras y se prueban con Jest sin Angular. sinSoloEspacios({value: ' '} as AbstractControl) devuelve {soloEspacios: true}. Es la misma facilidad de prueba que tenían tus validadores de 03-03 y tus reductores de 10-03.
• limiteSemanal es una fábrica de validadores —una función que devuelve una función, de 03-06— porque necesita datos externos. Y es un validador de grupo, porque la R7 depende de dos campos a la vez.
• El objeto de error lleva datos, no solo true. Eso permite mensajes concretos: «Iván llegaría a 45 h de las 40 permitidas» en lugar de «error». Es la misma idea que tu ErrorDeValidacion con .campo de js/modelo/errores.js.

Angular trae su propio entorno, que monta un mini-inyector para la prueba:

La línea que importa es providers: [{ provide: TareasService, useValue: servicioFalso }]. Eso es lo que compra la inyección de dependencias. El componente pide TareasService; en producción recibe el real, en la prueba recibe el doble, y el componente no cambia ni se entera. Es exactamente lo que hiciste a mano en 08-04 pasando AlmacenEnMemoria al constructor de RepositorioLocal, con el cableado automatizado.

Angular incluye Karma y Jasmine por defecto, pero se puede usar Jest o Vitest, y Testing Library tiene versión para Angular, con las mismas consultas por rol que ya usas desde 08-05. La filosofía de probar lo que ve la usuaria no cambia de framework.

Angular incluye renderizado en servidor sin librerías externas:

Eso añade un servidor que renderiza el HTML antes de enviarlo, con hidratación en el cliente para que la página siga siendo interactiva, y soporte para hidratación incremental combinada con @defer, que permite decidir qué partes se hidratan y cuándo.

No lo desarrollamos aquí: el renderizado en cliente, servidor, estático e híbrido es el tema de la próxima lección, donde verás por qué esa decisión suele importar más que la del framework.

Cuarta y última versión de la misma pantalla. El dominio, en TypeScript pero conceptualmente idéntico:

El servicio, que es donde vive el estado:

La tarjeta es la del apartado 13. La lista:

Y el componente raíz:

Los números canónicos, comprobados: sin filtro, «6 de 6 tareas · 45 h abiertas». Con «Iván», «3 de 6 · 25 h». Con «Lucía», «1 de 6 · 14 h». Con «Marta», «2 de 6 · 6 h».

Y las métricas de la misma pantalla, con las cuatro versiones:

Lo que gana Angular, sin adornos: cohesión total. Todo encaja porque lo hizo el mismo equipo. El tipado es de serie y atrapa errores antes de ejecutar. El track obligatorio impide un fallo real. Los servicios inyectados dan estado compartido y capacidad de prueba sin instalar nada. Las migraciones automáticas hacen viables las actualizaciones a diez años vista. Y dos proyectos distintos se parecen, lo que reduce el coste de incorporar a alguien.

Lo que pierde, con la misma franqueza: es el más caro de aprender, con diferencia. TypeScript, decoradores, inyección de dependencias, señales, RxJS y dos sistemas de formularios son mucho antes de la primera pantalla. Es el más verboso: 180 líneas frente a 120 para lo mismo. Es el más pesado en el arranque. Y es el que peor encaja en proyectos pequeños, donde toda esa infraestructura no tiene nada que sostener.

Olvidar los paréntesis al leer una señal. tarea.titulo en lugar de tarea().titulo compara o accede sobre la función, no sobre el valor. En la plantilla, {{ tareas }} muestra el código de la función. TypeScript detecta muchos de estos casos, pero no todos.

Mutar el valor de una señal. tareas()[0].estado = 'hecha' no dispara nada: las señales comparan con Object.is. Hay que usar update con un map inmutable, como en React.

Olvidar imports en un componente independiente. Si la plantilla usa <app-tarjeta-tarea> o [formGroup] y no está en imports, el error de compilación es claro pero desconcierta al principio. Es el precio de que cada componente declare lo que necesita.

Usar propiedades de clase en lugar de señales. Funciona por Zone.js, pero es el modelo antiguo: pierdes el grano fino, impides la estrategia zoneless y mezclas dos sistemas de reactividad. Para código nuevo, señales.

Llamar a un método en la plantilla en lugar de a un computed. {{ calcularHoras() }} se ejecuta en cada ciclo de detección de cambios, que con Zone.js puede ser muchísimas veces por segundo. computed se cachea. Es la causa clásica de que una aplicación Angular vaya lenta sin motivo aparente.

No suscribirse a un observable. Los observables son perezosos: sin subscribe no ocurre nada. Es la trampa número uno para quien viene de promesas, que se ejecutan al crearse.

No darse de baja. Es la fuga de memoria de 09-03 con otro nombre. Usa el pipe async en la plantilla o takeUntilDestroyed; nunca dejes una suscripción a un flujo infinito sin gestionar.

Poner lógica de negocio en los componentes. En Angular es especialmente evitable porque los servicios existen precisamente para eso, con inyección y pruebas incluidas. La disciplina de 10-01 se aplica igual: el dominio es TypeScript puro, el componente pinta.

Usar ngModel para formularios complejos. Angular recomienda los formularios reactivos para todo lo que no sea trivial: tipado, validación asíncrona, campos dinámicos y pruebas sin renderizar.

Consejo: aprende TypeScript antes que Angular. Intentar aprender los dos a la vez multiplica la confusión, porque no sabrás si un error es del lenguaje o del framework. La lección 11-07 es el punto de partida.

Consejo: empieza con señales y deja RxJS para la capa de datos. El Angular moderno permite escribir casi toda la aplicación con señales y usar observables solo donde aportan —HTTP, WebSocket, secuencias con cancelación—. toSignal es el puente.

Consejo: usa ng generate siempre. Genera la estructura correcta, el fichero de pruebas y los registros necesarios. Escribir componentes a mano es una fuente de errores tontos que la CLI evita.

Traduce este componente de React (de 10-02) a un componente Angular independiente con señales. Mantén el mismo comportamiento y respeta las reglas R6 y R10.

Indica en comentarios qué corresponde a useState, a las props y al cálculo derivado.

Escribe un servicio ApiTableroService que:

1. Exponga tareas, cargando y error como señales de solo lectura.
2. Tenga un método filtrarPor(responsable: string | null) que actualice una señal interna.
3. Cargue las tareas del servidor cada vez que cambie el responsable, con debounceTime(300) y cancelando la petición anterior.
4. Reintente tres veces con medio segundo de espera ante un fallo de red.
5. Ante un error definitivo, deje la lista vacía y rellene error sin romper el flujo.

Usa toObservable, switchMap, retry, catchError y toSignal. Explica qué operador resuelve la condición de carrera de 10-02 y por qué.

Escribe tres funciones puras, sin dependencias de Angular en su lógica, y sus pruebas:

1. Un validador horasEnRango para la R3 (mayor que 0, máximo 40) que devuelva un error con datos útiles para el mensaje.
2. Una función puedeAvanzar(estadoActual, destino) que implemente la R6 usando SIGUIENTE, y explica por qué no es un validador de formulario.
3. Un validador de grupo fechaCoherenteConEstado que aplique la R10 al revés: si el estado es 'hecha', la fecha límite pasada no debe marcar error; si no es 'hecha' y la fecha ya pasó, debe devolver un aviso (no un error bloqueante).

Después responde: ¿por qué conviene que estas funciones vivan en dominio/ y no en el componente?

Solución 1

Diferencias notables respecto al original:

• Las filas se transforman a un array de objetos con nombre dentro, en lugar de pares [clave, valor]. En la plantilla de Angular, la desestructuración de @for es más limitada que en JSX, y un objeto se lee mejor.
• track fila.nombre es obligatorio: sin él, el proyecto no compila. En la versión React, key era un aviso que se puede ignorar.
• La lógica de agrupación podría —y probablemente debería— vivir en dominio/carga.ts como función pura, dejando el componente solo con la presentación. Con el backlog canónico devuelve: Iván 3 / 25 h, Lucía 1 / 14 h, Marta 1 / 6 h.

Solución 2

Qué operador resuelve la condición de carrera: switchMap. Su semántica es «cambia al flujo nuevo y cancela la suscripción al anterior». Cuando Marta pasa de «Iván» a «Lucía», la petición de Iván se cancela en el momento en que llega el valor de Lucía. Al cancelarse la suscripción, HttpClient aborta la petición HTTP subyacente —usa internamente el mismo mecanismo que tu AbortController de 07-03—, así que su respuesta nunca llega al tap ni al toSignal. La carrera es imposible por construcción, no por una comprobación que alguien haya escrito.

Compara las tres soluciones al mismo problema:

Dos detalles del código: catchError devuelve of([]) en lugar de relanzar, porque si el error propaga, el flujo termina y filtrarPor deja de funcionar para siempre — es el error clásico de RxJS. Y retry va dentro del switchMap, aplicado a la petición concreta; si estuviera fuera, reintentaría todo el flujo externo, incluido el debounceTime.

Solución 3

Las pruebas, con Jest y sin Angular:

Por qué puedeAvanzar no es un validador de formulario. Un validador comprueba si un valor introducido es aceptable. La R6 no habla de valores sino de transiciones: depende del estado anterior, que no está en el formulario. Es una regla del modelo, y su sitio natural es el servicio —donde ya la aplica avanzar()— y el botón, que se deshabilita cuando SIGUIENTE[estado] es null. Meter reglas de transición en la capa de formularios es un error de ubicación que acaba duplicando la lógica.

Por qué el dominio va en dominio/. Cuatro razones, y las cuatro las has visto ya en este módulo:

1. Se prueba sin framework. Las pruebas de arriba se ejecutan en milisegundos, sin TestBed, sin jsdom y sin renderizar nada.
2. Se reutiliza en todas las capas. El componente, el servicio, el enrutador y —si el servidor comparte código— la API usan las mismas funciones.
3. Sobrevive al framework. Es exactamente la disciplina de 10-01: dominio/reglas.js ha sido el mismo fichero en las cuatro versiones de esta pantalla. Cambiar de framework es reescribir la vista, no la aplicación.
4. Es donde el negocio se lee. Alguien que quiera saber qué reglas rigen Nómada Tareas abre una carpeta, no rebusca por los componentes.

Has visto el cuarto y último enfoque del módulo, y el más distinto de todos.

Sabes qué es Angular como plataforma completa: enrutador, cliente HTTP, dos sistemas de formularios, inyección de dependencias, RxJS, generación de código, entorno de pruebas, internacionalización, SSR y migraciones automáticas, todo oficial y actualizado a la vez. Entiendes qué significa «con opiniones» llevado hasta el final —no eliges herramientas, la estructura viene dada, hay una forma correcta de cada cosa, la verbosidad es deliberada, y la curva es empinada al principio y plana después— y en qué perfil de proyecto compensa: aplicaciones grandes, longevas, con equipos numerosos y rotación de personal.

Tienes lo mínimo de TypeScript para leer el código —anotaciones que desaparecen al compilar, interfaces que describen la forma de un objeto, tipos de unión literal que convierten las reglas R1–R10 en cosas que el compilador impide expresar, genéricos que se leen como «X de Y», y modificadores de acceso con el matiz de que private no es #privado—, con la remisión a 11-07 para aprenderlo en serio. Y sabes qué son los decoradores: metadatos declarados encima de una clase, coherentes con la filosofía de que la configuración viva junto a lo que configura.

Conoces la CLI y lo que dice de las opiniones de Angular —que ng generate component cree un fichero de pruebas por defecto no es un detalle—, y los componentes independientes con sus imports, que hoy sustituyen a los NgModule. Dominas las cuatro formas de enlace de datos con la mnemotecnia de los corchetes hacia dentro y los paréntesis hacia fuera, y [(ngModel)] desmitificado como el v-model de Vue: una propiedad que baja y un evento que sube. Y manejas la sintaxis de control de flujo actual —@if/@else, @for con @empty, @switch— con sus cuatro ventajas sobre las directivas antiguas, y @defer con sus disparadores, su @placeholder, su @loading y su @error, que hace declarativamente todo lo que escribiste a mano en 09-05.

Sabes que el track de @for es obligatorio y que sin él el proyecto no compila: la misma clave estable de tu reconciliar de 06-06, elevada de aviso a error, que es «con opiniones» en su forma más útil. Dominas las señales —signal con set y update, computed cacheado y perezoso, effect con su limpieza— y sabes que, a diferencia de Vue, comparan con Object.is y por tanto la inmutabilidad de 04-07 vuelve a ser obligatoria, con la contrapartida de que una señal nunca se pierde al desestructurar. Conoces Zone.js y por qué existía —comprobarlo todo porque no se sabía qué había cambiado—, y la tendencia zoneless que las señales hacen posible.

Entiendes la inyección de dependencias: servicios con @Injectable({providedIn: 'root'}), inject() que pide un tipo en lugar de importar una instancia, el patrón de señal privada escribible más señal pública de solo lectura que es la encapsulación de 05-03 aplicada al estado, y las cuatro capacidades que compra —sustituir en pruebas, cambiar por entorno, controlar el ámbito, e interceptar—. Y sabes que ya la practicaste en 08-04, cuando pasaste AlmacenEnMemoria al constructor de RepositorioLocal para poder probar sin localStorage: Angular hace de ese patrón la norma y automatiza el cableado.

Tienes lo justo de RxJS: un observable es un flujo de valores en el tiempo, es perezoso y no ocurre nada sin subscribe —la trampa número uno para quien viene de promesas—, pipe encadena operadores, y los siete que aparecen siempre tienen equivalente en algo que ya escribiste: map, filter, retry (tu conReintentos), catchError, debounceTime (tu debounce de 09-02), switchMap (tu AbortController) y takeUntilDestroyed (tu destruir()). Sabes por qué hay que darse de baja —es la fuga de 09-03 con otro nombre— y las tres formas correctas de hacerlo, y tienes el criterio para elegir entre señales y observables, con toSignal y toObservable como puentes.

Conoces el enrutador con carga perezosa vía loadComponent, que es el import() dinámico de 09-05 integrado, con guardas que tu enrutador.js no tenía; los formularios reactivos frente a los de plantilla con la tabla que decide; y validadores que son funciones puras implementando la R2, la R4, la R7 y la R9, con errores que llevan datos para producir mensajes útiles, en la línea de tu ErrorDeValidacion con .campo. Y sabes probar con TestBed, donde la línea providers: [{provide: TareasService, useValue: falso}] es la demostración práctica de qué compra la inyección de dependencias.

Has escrito la cuarta versión de la misma pantalla —~180 líneas, con el dominio en TypeScript pero conceptualmente idéntico a los tres anteriores— y tienes la tabla comparativa completa: Angular gana en cohesión, tipado de serie, track obligatorio, servicios inyectados, migraciones automáticas y previsibilidad entre proyectos; y pierde en curva de aprendizaje, verbosidad, peso y encaje en proyectos pequeños.

Ya has visto los cuatro enfoques con la misma pantalla escrita cuatro veces. Queda la pregunta que da sentido a todo el módulo, y que no tiene una respuesta única: cómo se elige. En la última lección vas a poner las cuatro versiones una al lado de otra con sus métricas, a ordenar los criterios que de verdad importan —producto, equipo, mercado, longevidad, rendimiento, SEO, accesibilidad, coste—, y a descubrir que hay una decisión que suele pesar más que la del framework: dónde se renderiza. Y cerrarás conectando con el proyecto final, que se construye en JavaScript puro y que a partir de ahora será una decisión informada: Elegir el Framework Adecuado.