Code splitting del store: inyectar reducers a destiempo

Las cuatro lecciones anteriores trataron la estructura como algo estático: dónde vive cada cosa y quién puede mirar a quién. Esta introduce el tiempo. Si el panel de administración se carga solo cuando alguien lo abre, su código de vista viaja en un paquete aparte, pero su slice suele quedarse en el arranque, importado por el fichero del store, arrastrando al paquete inicial la lógica de estado de una pantalla que la mayoría de los usuarios no verá. El corte de código a medias es un corte que no corta. La salida existe desde las primeras versiones de Redux y está en un método que casi nadie usa: replaceReducer. Con él, el árbol de reducers deja de ser una constante fijada al arrancar y pasa a ser una estructura que crece cuando el código llega, con las consecuencias que eso tiene sobre los tipos, sobre el orden de las acciones y sobre la limpieza.

Por qué el slice arruina el corte

Un corte de código funciona por alcanzabilidad: el empaquetador incluye en el paquete inicial todo lo que se pueda alcanzar por importaciones estáticas desde el punto de entrada, y aparta tras una importación dinámica lo que no. El fichero del store es un punto de entrada de facto, porque para componer el árbol de reducers importa todos los slices; en cuanto un slice aparece ahí, su módulo entero —y todo lo que él importe— vuelve al arranque aunque su pantalla esté perfectamente diferida.

El efecto suele ser mayor de lo que parece, porque un slice rara vez viaja solo: arrastra sus tipos, sus adaptadores de entidad, sus thunks y, con ellos, los clientes de datos y las utilidades de validación que esos thunks usan. Es habitual descubrir que la pantalla más pesada del producto está correctamente diferida en su vista y completamente presente en su lógica. Antes de complicar nada conviene medir si el ahorro compensa: la inyección diferida introduce complejidad real, y solo la justifican módulos que pesan de verdad y que una fracción minoritaria de usuarios llega a abrir.

El gestor de reducers a mano

El mecanismo cabe en unas pocas líneas y merece escribirse una vez, porque explica todo lo que las APIs modernas hacen por debajo. Un gestor mantiene un diccionario de reducers, recombina y llama a replaceReducer cada vez que alguien registra uno nuevo.

import { combineReducers, type Reducer } from '@reduxjs/toolkit'

export function crearGestor(inicial: Record<string, Reducer>) {
  const reducers = { ...inicial }
  let combinado = combineReducers(reducers)
  return {
    reducer: (estado: any, accion: any) => combinado(estado, accion),
    añadir(clave: string, r: Reducer) {
      if (reducers[clave]) return
      reducers[clave] = r
      combinado = combineReducers(reducers)
    },
  }
}

// al cargar la pantalla diferida
const gestor = crearGestor({ sesion: sesionReducer })
gestor.añadir('admin', adminReducer)
store.replaceReducer(gestor.reducer)

Conviene entender con precisión qué hace replaceReducer. Sustituye la función reductora del store y despacha una acción interna de reemplazo para que el nuevo árbol se inicialice; no borra el estado existente, porque combineReducers conserva las ramas cuyo reducer sigue presente y da valor inicial a la nueva. Tampoco reprocesa el historial: las acciones anteriores no se vuelven a aplicar sobre el reducer recién llegado, y esa es justamente la fuente del problema de orden que se trata más abajo.

La forma idiomática en 2026

Redux Toolkit incorporó el patrón en su versión 2 con combineSlices, que sustituye a combineReducers y añade un método de inyección. La diferencia con el gestor artesanal no es de mecanismo sino de tipos: combineSlices mantiene el tipo del estado raíz al día, marcando como opcionales las ramas que aún no se han inyectado, y devuelve al inyectar una versión del slice cuyos selectores saben que su rama ya existe.

import { combineSlices } from '@reduxjs/toolkit'
import { sesionSlice } from '../features/sesion/sesionSlice'

// las ramas diferidas se declaran, no se importan
export const rootReducer = combineSlices(sesionSlice).withLazyLoadedSlices()

// dentro del modulo diferido, al cargarse
const adminInyectado = rootReducer.inject(adminSlice)
export const { selectPendientes } = adminInyectado.selectors

RTK Query tiene su propia versión del mismo gesto: un único servicio base creado con createApi y, en cada módulo diferido, un injectEndpoints que le añade sus endpoints cuando el módulo llega. El resultado es que la caché sigue siendo una sola —una sola rama, una sola configuración, una sola invalidación por etiquetas— mientras la definición de los endpoints se reparte entre los paquetes de cada funcionalidad. Es la aplicación más limpia del principio de este nivel: la unidad de código diferido sigue siendo el dominio, y lo que se difiere es su definición, no su infraestructura.

Los cuatro problemas de llegar tarde

El primero es de tipos. Si una rama puede no existir todavía, el tipo honesto del estado raíz la declara opcional, y todo selector escrito contra ella debe contemplar el caso ausente. La API de inyección resuelve esto devolviendo selectores que asumen la rama presente, lo cual es correcto porque solo se obtienen después de inyectar; escrito a mano, el atajo de mentir en el tipo con una aserción es tentador y convierte un error de compilación en un fallo en ejecución.

El segundo es de orden. Una acción despachada antes de que su reducer exista no se pierde para el registro de las DevTools, pero no produce efecto sobre el estado y no se reprocesa al inyectar. Aparece cuando un middleware, una notificación de servidor o un enlace profundo despachan hacia una funcionalidad que aún no ha cargado. La disciplina que lo evita es sencilla: la inyección debe formar parte de la carga del módulo, no de la primera renderización de su componente, de modo que la rama exista antes de que nada pueda dirigirse a ella.

sequenceDiagram
participant U as usuario
participant R as router
participant M as modulo diferido
participant S as store
U->>R: navega a la ruta admin
R->>M: importacion dinamica
M->>S: inject del slice admin
S->>S: replaceReducer con el arbol nuevo
M->>S: dispatch de acciones de admin
Note over S: si el dispatch llega antes del inject no hay efecto

// Precarga de una rama que aun no existe: se guarda y se aplica al inyectar
const pendiente = window.__ESTADO__?.admin

function inyectarAdmin() {
  const inyectado = rootReducer.inject(adminSlice)
  if (pendiente) store.dispatch(adminSlice.actions.hidratar(pendiente))
  return inyectado
}

// Retirada de una rama: sustituir por un reducer que devuelve indefinido
function retirar(clave: string) {
  reducers[clave] = () => undefined
  store.replaceReducer(combineReducers(reducers))
  delete reducers[clave]
}

El tercero es la precarga. El estado inicial que se pasa al crear el store solo alimenta las ramas presentes en ese momento; el resto se descarta salvo que el gestor lo conserve. En una aplicación con renderizado en servidor, esto significa que el estado serializado de una rama diferida debe guardarse aparte y aplicarse en el momento de la inyección, o que esa rama no debe formar parte de la precarga en absoluto. El cuarto es la limpieza: al desmontar la funcionalidad, su rama permanece con el último estado que tuvo. Retirarla es posible sustituyendo el reducer por uno que devuelva indefinido y eliminando la clave, pero hay que hacerlo sabiendo que cualquier selector superviviente encontrará la rama ausente. Casi siempre la decisión sensata es dejarla: la memoria que ocupa es despreciable y la vuelta a la pantalla resulta instantánea.

Queda una consecuencia que no es un problema sino un beneficio inesperado: la inyección obliga a que cada dominio declare explícitamente cuándo entra en el store, y esa declaración es una prueba viva de que su frontera está bien puesta. Un slice que se puede inyectar tarde es un slice del que nadie depende antes de tiempo; si al diferirlo aparecen selectores rotos en otras funcionalidades, no has descubierto un problema de carga diferida, has descubierto un acoplamiento que la tercera lección del nivel te habría hecho ver.