La URL como fuente de verdad

Hay una clase de estado que casi nadie coloca donde debe. Los filtros de un catálogo, el número de página, la pestaña activa, el término de búsqueda, el orden de una tabla, el rango de fechas de un informe: por reflejo, todo eso acaba en un useState, y con ello se pierde algo valiosísimo. Se pierde la capacidad de compartir la vista por un enlace, de volver atrás con el navegador, de recargar sin perder el contexto, de guardar en favoritos un estado concreto. La URL no es una decoración de la página ni una mera dirección de recurso: es el único estado de tu aplicación que el usuario puede copiar, marcar y enviar a otra persona. Es un store, y uno con propiedades que ninguna librería de cliente te regala. Este nivel entero trata de reconocer esa clase de estado y devolverla a su sitio.

La dirección es estado, no decoración

Mira una URL con ojos de arquitecto de estado y no de diseñador de rutas: catalogo/camisetas?color=azul&talla=m&page=2&sort=precio. Cada parámetro es una entrada de un store, y el conjunto describe por completo una vista. Pero es un store con cuatro propiedades que ningún useState, ningún Zustand y ningún contexto te dan gratis. Es compartible: el texto reproduce la vista exacta en otro navegador. Es navegable: el botón atrás recorre el historial de estados anteriores. Es recargable: pulsar F5 no destruye nada. Y es direccionable: un enlace apunta a un estado concreto, no solo a una página.

Lo decisivo es entender de dónde nacen esas propiedades. No son funcionalidades que una librería añada, sino consecuencias de una única decisión: el estado vive en texto que el navegador entiende, sincroniza entre pestañas, guarda en el historial y expone a copiar y pegar. Es memoria externa a tu aplicación, gobernada por la plataforma y no por tu framework. Por eso sobrevive a un recargado que destruye toda la memoria de JavaScript, y por eso un enlace funciona en una máquina que jamás ejecutó tu código. La URL es el único estado que forma parte del contrato de la web, y las cuatro propiedades no se construyen: se heredan por poner el dato en el sitio correcto.

const params = new URLSearchParams(location.search);
const page = Number(params.get('page') ?? '1');
const filtro = params.get('q') ?? '';

// al cambiar el filtro escribimos en la URL, no en un useState paralelo
params.set('q', nuevoFiltro);
params.set('page', '1'); // un filtro nuevo reinicia la paginacion
history.pushState(null, '', `?${params.toString()}`);

La consecuencia práctica es tajante. El mismo filtro guardado en memoria y guardado en la URL producen interfaces que parecen idénticas mientras nadie las toca, y radicalmente distintas en cuanto el usuario ejerce una de las cuatro afordancias. La memoria muere al recargar, no viaja en el enlace y no deja rastro en el historial; la URL hace las tres cosas sin una línea extra. Elegir entre ambas no es una preferencia de estilo: es decidir qué capacidades tendrá el usuario.

El estado navegable es una clase, no un caso

La taxonomía del estado que recorre este track distingue el estado local, el global de cliente, el del servidor y el de la URL. El error habitual es tratar los tres primeros como categorías serias y el cuarto como un rincón menor donde caen los filtros por casualidad. Es al revés: el estado navegable es una clase de primera categoría, y lo que la define no es un tipo de dato sino una propiedad —la de merecer ser direccionable—. Dos datos del mismo tipo, dos strings, pueden pertenecer a clases distintas: el término de una búsqueda confirmada es navegable, el texto de un campo a medio escribir no lo es, aunque ambos sean cadenas.

Reconocer esta clase cambia el orden de las decisiones. No preguntas primero “¿qué librería de estado uso?” y luego “¿la hago compartible?”; preguntas primero “¿este dato es navegable?”, y esa respuesta determina la ubicación antes de que la herramienta entre en escena. La clase precede a la herramienta, y en el caso de la URL la precede de forma especialmente nítida, porque la propiedad que define la clase —ser direccionable— solo la satisface un lugar.

El criterio de una sola pregunta

El criterio se vuelve operativo cuando lo reduces a una prueba que puedes recitar de memoria: si un usuario pudiera querer, alguna vez, compartir por enlace, guardar en favoritos o recargar y recuperar esta misma vista, entonces su estado pertenece a la URL. Filtros, búsqueda, paginación, orden, pestaña seleccionada, rango de fechas: todo eso es navegable por naturaleza, porque describe qué está mirando el usuario. Lo que no va en la URL es lo efímero y privado: si un menú está abierto, el texto a medio escribir de un campo, la posición del cursor, el hover de un botón. Ese estado es local, muere con la sesión y a nadie le importa reproducirlo.

El oficio aparece en el gradiente entre ambos extremos. El caso canónico es el buscador: el término final es navegable —quiero compartir la búsqueda de “botas de agua”—, pero cada pulsación intermedia no lo es, porque ensuciar el historial con veinte estados por una sola palabra es hostil. La resolución no es dudar, sino separar dos cosas que parecen una: el valor efímero mientras se teclea vive local, y solo se promueve a la URL al confirmar o tras un debounce.

function Buscador() {
  const [borrador, setBorrador] = useState('');   // efimero: no navegable
  const debounced = useDebounce(borrador, 300);

  useEffect(() => {
    // se PROMUEVE a la URL solo el valor estabilizado, ya navegable
    const p = new URLSearchParams(location.search);
    debounced ? p.set('q', debounced) : p.delete('q');
    history.replaceState(null, '', `?${p}`);       // replace: no ensucia el historial
  }, [debounced]);
}

Las tres regiones y sus semánticas

Una URL no es un saco uniforme: tiene tres regiones con contratos distintos, y ubicar cada dato en la correcta es parte de la disciplina. Los path params —/producto/42— identifican el recurso principal y forman parte de la ruta; su ausencia cambia qué página es, no cómo se ve. Los search params —?color=azul&page=2— modelan el estado secundario y opcional de la vista: filtros, orden, paginación; su ausencia deja una vista por defecto perfectamente válida. Y el hash —#seccion-3— apunta a una posición dentro del documento y ni siquiera viaja al servidor.

La gran mayoría del estado navegable vive en los search params, y no por casualidad: son opcionales, combinables y no rompen la ruta si faltan. Esa opcionalidad es exactamente la propiedad que necesita un filtro, que puede estar o no estar sin invalidar la página. Confundir las regiones —meter un filtro en el path, o el identificador del recurso en un search param— produce URLs frágiles: rutas que dejan de resolver cuando falta un dato que debería ser opcional, o recursos que se pierden al limpiar los parámetros.

El ciclo completo, una vez el estado navegable está en la URL, tiene una sola dirección de la verdad, y verlo así previene el error que la lección 4 desmenuza: la URL manda, la vista la refleja, la interacción reescribe la URL, y no hay copia intermedia que pueda quedar obsoleta.

flowchart LR
U[URL con search params] --> P[parsear params]
P --> V[render de la vista]
V --> I[el usuario filtra pagina u ordena]
I --> W[escribir en la URL]
W --> U
style U fill:#89b4fa,color:#11111b
style V fill:#a6e3a1,color:#11111b
style W fill:#cba6f7,color:#11111b