NgRx en Angular: el mismo patrón con RxJS

Si Redux es agnóstico, cabe esperar que otros ecosistemas lo hayan adoptado con sus propios materiales, y el caso más literal es NgRx en Angular. No es un gestor inspirado en Redux ni un primo lejano: es Redux, con acciones, reducers puros, un único árbol de estado y DevTools incluidos, reescrito sobre RxJS y sobre el inyector de dependencias de Angular. Quien llega a NgRx desde este track no tiene que aprender un modelo nuevo, sino un diccionario: donde decías useSelector ahora dices store.select, donde decías middleware ahora dices Effects, y donde tenías una suscripción manual ahora tienes un Observable al que el framework se suscribe por ti. La lección de hoy hace esa traducción palabra por palabra y examina qué cambia de verdad cuando el flujo unidireccional se expresa como un stream.

El mismo patrón, otro diccionario

La estructura de NgRx es reconocible línea a línea para quien viene de Redux Toolkit. Hay acciones con tipo y carga, hay reducers puros que reciben estado y acción y devuelven estado nuevo, hay un store único e inmutable, hay selectores memoizados equivalentes a los de Reselect y hay una extensión de navegador que muestra el historial. Incluso la variante moderna, createFeature, reduce el boilerplate con la misma estrategia que createSlice: agrupar acciones, reducer y selectores en una declaración cohesionada.

Conviene subrayar que esta correspondencia no es una coincidencia ni una inspiración vaga: NgRx se presentó explícitamente como Redux para Angular y mantuvo la compatibilidad con la extensión de Redux DevTools precisamente para heredar su instrumental. Cuando leas su documentación reconocerás los tres principios del Nivel 2 enunciados casi con las mismas palabras, y cuando depures verás el mismo historial de acciones con el mismo viaje en el tiempo. Ese parentesco declarado es lo que convierte a NgRx en el mejor primer puerto del nivel: no hay que buscar el patrón bajo el disfraz, porque el disfraz es transparente.

La diferencia estructural con Redux es que en NgRx todo se registra en el inyector de Angular en lugar de componerse a mano en un archivo de configuración. El store, los efectos y las funcionalidades se declaran como proveedores, y los componentes los reciben por inyección de dependencias. Esto suena a detalle administrativo, pero tiene una consecuencia real: la disciplina que en React había que imponer con convenciones de carpetas —dónde vive el reducer, quién compone el store, quién registra el middleware— en Angular la impone el propio sistema de módulos y proveedores.

El store es un stream

La traducción más importante no es de nombres sino de forma. En Redux, el store es un objeto al que preguntas por su estado; en NgRx, el store es un Observable que emite el estado cada vez que cambia. Seleccionar no devuelve un valor, devuelve otro Observable derivado. Y la vista no lee: se suscribe.

import { Component, inject } from '@angular/core'
import { Store } from '@ngrx/store'
import { seleccionarPendientes } from './tareas.selectors'
import { tareasActions } from './tareas.actions'

@Component({
  selector: 'app-tareas',
  template: `
    <p>Pendientes: {{ pendientes() }}</p>
    <button (click)="completar()">Completar una</button>
  `,
})
export class TareasComponent {
  private store = inject(Store)

  // selectSignal convierte el stream en una senal sincrona y legible en plantilla
  pendientes = this.store.selectSignal(seleccionarPendientes)

  completar() {
    this.store.dispatch(tareasActions.completarPrimera())
  }
}

Ese fragmento contiene la lección entera de la lección anterior en versión Angular: el store se obtiene por inyección en lugar de por contexto, el selector memoizado hace el mismo trabajo que useSelector, y dispatch es idéntico. Lo único genuinamente distinto es que la capa de enlace no la escribes tú ni la aporta un paquete de integración: la aporta el sistema de reactividad del framework, que sabe suscribirse a un Observable con la tubería async o convertirlo en una señal.

Effects: dónde vive el efecto en Angular

En el Nivel 4 dedicamos una lección entera a la pregunta de dónde vive el efecto, y NgRx responde con la solución más elegante que ha dado el ecosistema: un efecto es una función que transforma el stream de acciones en otro stream de acciones. No es un thunk que despacha manualmente, ni una saga con generadores; es una tubería declarativa que dice qué acciones escucha, qué trabajo impuro hace y qué acción emite al terminar.

cargarTareas = createEffect(() =>
  this.acciones.pipe(
    ofType(tareasActions.cargar),
    switchMap(() =>
      this.api.traerTareas().pipe(
        map((tareas) => tareasActions.cargaExitosa({ tareas })),
        catchError((error) => of(tareasActions.cargaFallida({ error: error.message }))),
      ),
    ),
  ),
)

Hay una propiedad de este diseño que merece nombre propio porque no la tiene ninguna de las alternativas que vimos en el Nivel 4: el efecto no conoce a quien lo disparó ni a quien consumirá su resultado. Solo declara qué tipo de acción escucha y qué tipos emite, de modo que la funcionalidad entera se acopla al flujo de acciones y no a componentes concretos. Eso permite añadir un segundo efecto que reaccione a la misma acción —registrar analítica, invalidar una caché, mostrar una notificación— sin tocar ni una línea del primero, y es la razón por la que en aplicaciones grandes la capa de efectos crece sin volverse un nudo.

Léelo despacio y reconocerás el ciclo de createAsyncThunk del Nivel 3 escrito en otra notación: una acción de inicio, una petición, una acción de éxito y una de fallo. Lo que RxJS añade es control explícito sobre la concurrencia mediante el operador que elijas: switchMap cancela la petición anterior si llega otra acción, concatMap las encola, exhaustMap ignora las nuevas mientras una está en curso, mergeMap las lanza todas en paralelo. Esa elección, que en un thunk queda implícita y suele ser fuente de bugs sutiles con respuestas fuera de orden, aquí es una decisión visible en una sola palabra.

Ese cuadro es, en la práctica, la mayor aportación de NgRx al patrón. En Redux con thunks la concurrencia se gestiona a mano —una bandera de carga, una comprobación de si la respuesta sigue siendo relevante, a veces un contador de peticiones— y ese código artesanal es donde se esconden los bugs difíciles de reproducir. Aquí la política de concurrencia es una decisión explícita, revisable en una revisión de código y cambiable en un carácter, lo que convierte una clase entera de errores en una elección de diseño visible.

flowchart LR
C[componente] -->|dispatch| A[stream de acciones]
A --> R[reducers puros]
R --> S[estado unico]
S --> SEL[selectores memoizados]
SEL -->|observable o signal| C
A --> E[effects con rxjs]
E -->|accion de exito o fallo| A
style A fill:#f9e2af,color:#11111b
style R fill:#a6e3a1,color:#11111b
style E fill:#f38ba8,color:#11111b

Por qué la ceremonia pesa menos aquí

Angular recorrió además el mismo camino que veremos en Vue con Pinia y en React con Zustand: junto al store clásico existe hoy NgRx SignalStore, una forma más ligera que declara estado, cálculos derivados y métodos en una sola pieza, sin acciones ni reducers explícitos, apoyándose en las señales para la notificación. Que el ecosistema con más ceremonia del mundo haya producido también su versión reducida confirma que la tendencia no es una moda de una comunidad concreta, sino la misma reevaluación en todas partes: cuando el entorno gana capacidad de observar cambios con grano fino, parte de la declaración explícita deja de ser necesaria.

El reproche estándar a NgRx es el mismo que hundió a Redux en React: demasiado boilerplate para lo que hace. Pero el reproche se evalúa siempre en relación con el coste base del ecosistema, y ahí Angular parte de otro sitio. Un desarrollador de Angular ya escribe módulos, ya declara proveedores, ya usa decoradores, ya compone tuberías de RxJS en los servicios y ya vive con tipado estricto. La ceremonia de NgRx no es un impuesto nuevo, sino más de lo que ya pagaba, y por eso su curva de adopción es mucho más suave que la de Redux para alguien que llegaba de un React minimalista.