Paso dos: slice a slice hacia Zustand

Terminada la extracción del servidor, lo que sobrevive dentro del store es por fin lo que su nombre prometía: estado que el cliente posee, que nadie más conoce y que no caduca solo. Ese resto es pequeño, y precisamente por serlo se puede mover con una técnica que sería temeraria a mayor escala: pieza a pieza, con el store antiguo y el nuevo funcionando a la vez durante semanas, y sin ninguna ventana en la que la aplicación quede a medio migrar de forma inconsistente. La clave de que esa convivencia sea segura no está en ninguna librería puente ni en ningún adaptador mágico, sino en una regla de propiedad tan simple que se puede sostener mentalmente: cada porción de estado tiene exactamente un dueño en cada instante del proyecto. Toda la técnica de esta lección consiste en respetar esa regla mientras el dueño cambia.

La regla de propiedad y por qué no se sincroniza

La tentación al empezar es construir un puente bidireccional: un middleware que copie cada cambio de Redux al store nuevo y una suscripción que devuelva los cambios del nuevo a Redux. Parece prudente porque garantiza que ambos lados vean lo mismo, y es la forma más fiable de arruinar la migración. Dos copias sincronizadas de un valor son dos fuentes de verdad con un contrato implícito que nadie escribe, y en cuanto aparece una escritura simultánea, un orden de eventos inesperado o un ciclo de eco entre los dos puentes, el sistema entra en estados que ninguna de las dos herramientas puede explicar por separado. Depurar eso cuesta más que la migración entera.

flowchart TD
C[componentes] --> H[hooks adaptadores]
H --> R[redux con slices pendientes]
H --> Z[zustand con slices migrados]
R -.->|un slice cruza una sola vez| Z
style R fill:#f38ba8,color:#11111b
style Z fill:#a6e3a1,color:#11111b
style H fill:#89b4fa,color:#11111b

El adaptador que desacopla la vista de la migración

Si los componentes llaman directamente a useSelector, migrar un slice obliga a tocar cada componente que lo lee, y el cambio atómico que exige la regla de propiedad se vuelve enorme y arriesgado. La solución es interponer una capa de hooks de dominio antes de mover nada: los componentes dejan de saber de qué store viene el dato y pasan a pedirlo por su nombre de negocio.

// paso previo: los componentes ya no conocen el store, solo el dominio
export function useTema() {
  return useSelector((s: RootState) => s.ui.tema)
}

export function useCambiarTema() {
  const dispatch = useDispatch()
  return (tema: Tema) => dispatch(uiSlice.actions.setTema(tema))
}

Con esa capa en su sitio, migrar el slice consiste en reescribir el interior de dos funciones. Ni un solo componente cambia, la superficie del cambio es diminuta y la reversión, si algo va mal, es igual de barata:

// despues: misma firma, otro dueno; los componentes no se enteran
interface EstadoUi { tema: Tema; setTema: (t: Tema) => void }

export const useUi = create<EstadoUi>((set) => ({
  tema: 'oscuro',
  setTema: (tema) => set({ tema }),
}))

export const useTema = () => useUi((s) => s.tema)
export const useCambiarTema = () => useUi((s) => s.setTema)

La capa de adaptadores tiene además un efecto que se aprecia mucho después de la migración: obliga a nombrar el estado por lo que significa en el dominio y no por dónde está guardado. Un componente que pide useTema describe una intención; uno que pide una ruta dentro del árbol describe una implementación. Esa diferencia de vocabulario sobrevive al proyecto y hace que el siguiente cambio de infraestructura, sea cual sea, vuelva a costar lo mismo que este: la reescritura de unas pocas funciones intermedias en lugar de una batida por todas las vistas.

El orden de los slices y el cierre

El orden importa porque el primer slice migrado es una clase, no una entrega. Empieza por el más trivial e independiente —un tema, una preferencia de interfaz, una bandera de panel abierto— para que el equipo aprenda el patrón de hooks adaptadores donde un error no cuesta nada. Sigue por los slices de tamaño medio con lectores dispersos, que es donde el adaptador demuestra su valor. Y deja para el final los que tienen dependencias cruzadas con otros slices, porque son los únicos que exigen decidir si viajan juntos en un mismo store o se separan.

// los slices interdependientes viajan juntos y se componen en un solo store
const crearSesion = (set) => ({
  usuario: null as Usuario | null,
  entrar: (u: Usuario) => set({ usuario: u }),
  salir: () => set({ usuario: null, favoritos: [] }),
})

const crearFavoritos = (set, get) => ({
  favoritos: [] as string[],
  alternar: (id: string) => set({ favoritos: alterna(get().favoritos, id) }),
})

export const useApp = create((...a) => ({ ...crearSesion(...a), ...crearFavoritos(...a) }))

Antes de aceptar ese acoplamiento como un hecho, conviene preguntarse si debería existir. Que una acción de sesión limpie los favoritos es a menudo el rastro de una decisión tomada cuando todo vivía en un mismo árbol y escribir en cualquier rama salía gratis. Si el vaciado puede expresarse como una reacción al cambio de sesión en lugar de como una escritura directa, los dos slices se desacoplan y pueden migrar por separado. La migración es un buen momento para hacer esa pregunta, siempre que la respuesta se implemente en un cambio propio y anterior, nunca mezclada con el traslado.

Ese fragmento contiene el motivo por el que dos slices acoplados no se migran por separado: salir limpia los favoritos, de modo que una acción de sesión escribe estado de favoritos. Si sesión viviera ya en Zustand y favoritos siguiera en Redux, esa acción tendría que despachar hacia el store antiguo, y eso es exactamente el puente que la regla de propiedad prohíbe. Cuando dos slices comparten una escritura, forman una unidad de migración.

Lo que se pierde por el camino y cómo suplirlo

Una migración honesta nombra también lo que deja atrás. Tres capacidades de Redux no vienen de fábrica en el destino, y conviene reponerlas de forma deliberada en lugar de descubrir su ausencia en la primera incidencia de producción. Dos se recuperan con middleware y son casi gratuitas; la tercera no se recupera del todo, y esa diferencia debería influir en la decisión de migrar.

// las piezas que reponen persistencia, inspeccion y escritura anidada comoda
export const useApp = create(
  devtools(
    persist(immer(crearEstado), { name: 'app', version: 2, migrate: migrar }),
    { name: 'app' },
  ),
)

La persistencia es la reposición más directa: el middleware correspondiente cubre lo que hacía redux-persist, incluida la versión del esquema guardado y la función de migración que traduce datos antiguos al formato nuevo. Conviene no omitir esa versión durante la migración, porque los usuarios que ya tenían estado persistido con el formato de Redux lo van a rehidratar con el store nuevo, y sin una migración explícita esa rehidratación produce estados imposibles que solo se manifiestan en las máquinas de quienes ya usaban la aplicación, jamás en desarrollo.