¿Cómo funciona la gestión de estado con NgRx?

Question

Accepted Answer

**NgRx** es una biblioteca de gestión de estado inspirada en Redux para Angular. Centraliza el estado de la aplicación en un único **store** inmutable, con un flujo de datos estricto, predecible y unidireccional construido sobre RxJS. ## Las piezas principales y el flujo ```text Component dispatches an ACTION → REDUCER produces new state (pure function) → STORE updates → SELECTORS read state → Component re-renders (EFFECTS handle side effects like HTTP, dispatching new actions) ``` ## Acciones — describen qué sucedió ```ts import { createAction, props } from "@ngrx/store"; export const loadUsers = createAction("[Users] Load"); export const loadUsersSuccess = createAction("[Users] Load Success", props<{ users: User[] }>()); ``` ## Reducer — función pura que calcula el siguiente estado ```ts import { createReducer, on } from "@ngrx/store"; export const usersReducer = createReducer( initialState, on(loadUsers, state => ({ ...state, loading: true })), on(loadUsersSuccess, (state, { users }) => ({ ...state, users, loading: false })), ); ``` Los Reducers son **puros** — dado el estado actual y una acción, devuelven un objeto de estado completamente nuevo (inmutablemente), nunca mutan el antiguo. ## Efectos — manejan efectos secundarios (HTTP, etc.) ```ts loadUsers$ = createEffect(() => this.actions$.pipe( ofType(loadUsers), switchMap(() => this.api.getUsers().pipe( map(users => loadUsersSuccess({ users })) // dispatch success with the data ) ) ) ); ``` Los Efectos escuchan acciones, realizan trabajo asincrónico (como HTTP) y envían acciones de resultado — mantienen los efectos secundarios fuera de componentes y reducers. ## Selectores + uso de componentes ```ts export const selectUsers = createSelector(selectUsersState, s => s.users); // memoized // component users$ = this.store.select(selectUsers); load() { this.store.dispatch(loadUsers()); } ``` ```html

``` ## ¿Cuándo vale la pena NgRx? ```text ✓ Large apps with lots of shared state across many components ✓ Complex state interactions, need for time-travel debugging / strict predictability ✗ Small/medium apps → it's heavy boilerplate; a service + signals/BehaviorSubject is simpler ``` (Nota: NgRx también ofrece un **SignalStore** y **ComponentStore** más ligeros para menos código repetitivo.) ## Por qué es importante NgRx trae la gestión de estado centralizada, predecible y unidireccional de Redux a Angular — valiosa para aplicaciones grandes donde muchos componentes comparten estado complejo, y donde la trazabilidad y depuración estrictas importan. Pero conlleva código repetitivo significativo, por lo que el juicio clave es *cuándo* usarlo (estado compartido grande/complejo) versus enfoques más simples (servicios con señales o `BehaviorSubject`) para aplicaciones más pequeñas. Comprender el flujo acción→reducer→store→selector y los efectos para efectos secundarios es fundamental para trabajar en bases de código de NgRx.