Errores frecuentes: el estado que se ensancha y el any que se cuela

Un proyecto con Redux y TypeScript rara vez falla porque alguien escriba un tipo incorrecto; falla porque en algún punto deja de haber tipo. Los dos mecanismos son casi opuestos y merecen nombres distintos. El primero es el ensanchamiento: el estado se declara implícitamente a partir de un valor inicial descuidado y acaba describiendo algo más ancho o más estrecho de lo que la aplicación guarda, con lo que el compilador aprueba asignaciones absurdas o rechaza asignaciones legítimas. El segundo es la infiltración de any, que no produce ningún error y por eso mismo es peor: allí donde entra, la comprobación se apaga en silencio y se propaga hacia dentro del estado sin dejar rastro. Esta lección cataloga ambos, muestra sus síntomas característicos y termina con las tres capas de blindaje que impiden que vuelvan.

El ensanchamiento: cuando el estado inicial miente

TypeScript infiere del valor inicial, y un valor inicial es casi siempre un caso particular pobre del conjunto de valores que el campo albergará. De ahí los tres síntomas clásicos. Un array vacío se infiere como array de nada, así que la primera inserción no compila. Un null se infiere como el tipo del propio null, así que asignar el objeto real tampoco compila. Y una cadena literal como el estado inactivo se ensancha a cadena genérica, con lo que la unión de estados que creías tener desaparece y el compilador acepta alegremente cualquier texto, incluida una errata. Los dos primeros molestan enseguida; el tercero es el peligroso, porque no da error nunca y solo se manifiesta como una condición que jamás se cumple.

La corrección canónica no es esparcir aserciones sobre los campos problemáticos sino declarar una interfaz para el estado y anotar con ella la constante inicial. Hacerlo así resuelve los tres casos a la vez y convierte esa interfaz en el documento de referencia del slice. Existe una alternativa que conviene entender para no usarla mal: comprobar el valor contra el tipo conservando los literales. Esa variante es excelente para constantes de configuración inmutables, pero contraproducente para un estado inicial, porque conservar el literal significa que el campo del estado queda fijado a su valor de partida y cualquier transición posterior deja de compilar.

interface Estado {
  items: Item[];
  seleccionado: Item | null;
  fase: "inactivo" | "cargando" | "listo";
}

// MAL: items es array de nada, seleccionado es null, fase es una cadena cualquiera
const malo = { items: [], seleccionado: null, fase: "inactivo" };

// BIEN: la anotacion fija la forma y conserva la union de fase
const inicial: Estado = { items: [], seleccionado: null, fase: "inactivo" };

// la variante que conserva literales: util para configuracion, nefasta para estado
const config = { fase: "inactivo", reintentos: 3 } satisfies Partial<Estado>;

// config.fase queda fijada al literal inactivo, asi que esto ya no compila
// config.fase = "cargando";

El contraste entre las dos formas ilustra una regla que va más allá de Redux: conservar literales sirve cuando el valor no va a cambiar nunca, y estorba cuando el valor es el punto de partida de una serie de transiciones. Un estado inicial pertenece siempre al segundo caso, porque su razón de ser es dejar de ser el inicial. Por eso la anotación con la interfaz es la herramienta correcta aquí, y la comprobación que preserva literales pertenece a los ficheros de configuración, a las tablas de rutas y a las constantes que se leen pero no se escriben.

Las vías por las que se cuela any

any tiene una propiedad que lo hace distinto de cualquier otro tipo: es contagioso y silencioso. Un valor de tipo any puede asignarse a cualquier destino sin queja, y todo lo que se derive de él lo hereda, de modo que basta con un punto de entrada para que una rama entera del estado deje de estar comprobada. Sus puertas habituales son cuatro. La primera y más frecuente es la red: el método que convierte una respuesta HTTP en objeto devuelve any, y ese valor viaja como payload de un thunk hasta instalarse en el estado. La segunda son las aserciones de conveniencia, que suelen aparecer justamente donde el tipado fallaba por las razones de las lecciones anteriores. La tercera son las dependencias con declaraciones pobres o inexistentes. Y la cuarta, más traicionera, es el ciclo de importación: cuando un slice importa RootState del store y el store importa el reducer del slice sin usar importación de solo tipos, el compilador puede no resolver el tipo y degradarlo a implícito, con lo que todos tus selectores dejan de comprobar nada mientras siguen compilando.

flowchart TD
A[respuesta de red convertida a objeto] -->|el metodo devuelve any| B[payload sin validar]
C[asercion de conveniencia] --> B
D[ciclo de importacion con RootState] --> E[tipo implicito]
B --> F[estado contaminado]
E --> F
F --> G[selectores que compilan y mienten]
H[validacion en la frontera] --> I[payload tipado de verdad]
I --> J[estado fiable]
style F fill:#f38ba8,color:#11111b
style J fill:#a6e3a1,color:#11111b

La distinción con unknown es la clave conceptual y merece enunciarse con precisión. any significa que el compilador renuncia a saber y te deja hacer cualquier cosa; unknown significa que el compilador no sabe y por eso no te deja hacer nada hasta que lo estreches. Ambos representan la misma ignorancia, pero uno la resuelve a tu favor y el otro a favor de la comprobación. Por eso la conversión correcta de un valor externo es a unknown seguida de una validación, y por eso los hooks modernos de react-redux prefieren dejar el estado como desconocido antes que como cualquiera.

// sonda para detectar any: solo any satisface esta condicion
type EsAny<T> = 0 extends 1 & T ? true : false;

type Sospecha = EsAny<ReturnType<typeof JSON.parse>>; // true, hay un agujero

// la conversion honesta: unknown y despues validacion
async function traerUsuario(id: string): Promise<Usuario> {
  const res = await fetch(`/api/usuarios/${id}`);
  const crudo: unknown = await res.json();
  return esquemaUsuario.parse(crudo); // aqui nace el tipo real
}

El caso del ciclo merece verse escrito porque su síntoma no se parece a nada. El slice importa el alias del store para tipar un selector, y el store importa el reducer del slice para construirse. Si esa importación de tipos no está marcada como tal, el compilador entra en una definición circular donde el tipo del estado depende del reducer que depende del tipo del estado, y el resultado no es un error rotundo sino una degradación: el alias se resuelve a un tipo implícito y todos los selectores que lo usan dejan de comprobar nada. El síntoma característico es que el autocompletado enmudece en un fichero concreto mientras el proyecto entero sigue compilando.

// features/todos/todosSlice.ts
import { RootState } from "../../app/store"; // importacion de valor: cierra el ciclo
export const seleccionarTotal = (estado: RootState) => estado.todos.lista.length;

// arreglo minimo: que la importacion se borre al compilar
import type { RootState } from "../../app/store";

Blindaje en tres capas

La primera capa es el compilador. El modo estricto es el punto de partida y no es negociable, pero hay dos opciones adicionales que cambian mucho el tipado de un estado Redux. Una obliga a tratar como posiblemente ausente todo acceso por índice, lo que afecta directamente al estado normalizado donde las entidades se leen por identificador y la ausencia es un caso real que la gente olvida. La otra distingue una propiedad ausente de una propiedad presente con valor indefinido, distinción que importa cuando se precarga estado parcial en pruebas. La segunda capa es la frontera: todo dato que llega de la red se valida con un esquema en el punto de entrada, de forma que el tipo del payload no sea una afirmación optimista sino el resultado de una comprobación real. La tercera capa es el lint, que convierte la disciplina en algo verificable.

// las tres opciones que mas cambian el tipado de un estado Redux
{
  "strict": true,
  "noUncheckedIndexedAccess": true,   // entities por id devuelve posible ausencia
  "exactOptionalPropertyTypes": true, // ausente no es lo mismo que indefinido
  "verbatimModuleSyntax": true        // obliga a marcar las importaciones de tipos
}

La segunda de esas opciones merece un comentario propio porque es la que más código rompe al activarla y también la que más errores reales destapa. En un estado normalizado, leer una entidad por su identificador puede no devolver nada, y sin esa opción el compilador finge que siempre devuelve algo: cada selector que lee un campo de la entidad recuperada está asumiendo una existencia que nadie garantizó. Activarla convierte esa suposición en un error de compilación en cada punto de lectura, y el trabajo de arreglarlos no es ruido, es escribir por fin la ramificación que la aplicación siempre necesitó para el caso de la entidad borrada o todavía no cargada.