Deep linking y compartir: el contrato de la plataforma

Cuando un estado vive en la URL, el usuario recibe tres capacidades sin que tú programes ni una: puede compartir la vista pegando el enlace en un chat, puede recorrer sus vistas anteriores con el botón atrás y rehacerlas con el de adelante, y puede guardar en favoritos un estado concreto para volver semanas después. Estas tres afordancias —compartir, navegar, marcar— no son funciones que tu aplicación construye, sino expectativas que el usuario importa de la plataforma. Ese matiz lo cambia todo. No estás añadiendo una característica: estás decidiendo si honras o rompes un contrato que el navegador ya firmó con el usuario mucho antes de que tu código existiera. Romperlo guardando los filtros en memoria no produce un error visible; produce una interfaz que se siente sutilmente rota, hostil de un modo que cuesta nombrar.

Tres afordancias que no construyes, heredas

La palabra clave es afordancia: una posibilidad de acción que el usuario percibe y espera antes de tocar tu producto. El botón atrás, la barra de favoritos y el gesto de copiar y pegar un enlace son afordancias del navegador, no de tu aplicación, y el usuario las trae aprendidas de las mil páginas que visitó antes que la tuya. Cuando pones el estado navegable en la URL, esas tres afordancias empiezan a funcionar sobre tu estado sin que escribas una línea, porque el navegador ya sabe compartir texto, apilar historial y guardar direcciones. Cuando lo pones en un useState, las tres siguen ahí en la interfaz —el botón atrás no desaparece— pero mienten: prometen una acción que ya no hace lo que el usuario espera.

Ese es el daño preciso de guardar estado navegable en memoria: no rompe una función que añadiste, rompe una promesa que el navegador hizo por ti. El usuario pulsa atrás esperando volver al filtro anterior y sale de la página entera; comparte el enlace y su compañero ve la vista por defecto en lugar de la filtrada; guarda en favoritos y al volver encuentra el estado inicial. Ninguno de esos fallos lanza un error ni aparece en un log. Es deuda de interfaz: invisible para las herramientas, palpable para la persona.

La pila del historial es un registro de deshacer gratis

Detrás del botón atrás hay una estructura que conviene ver con claridad: una pila de entradas de historial, cada una con su URL, que el navegador mantiene por ti. Atrás y adelante mueven un puntero por esa pila; cada navegación a una URL nueva empuja una entrada encima. Puesto en términos de estado, el historial es un registro de deshacer y rehacer, persistente y controlado por el usuario, que obtienes gratis por el mero hecho de escribir tus cambios de vista en la URL. Construir eso a mano —un undo stack de filtros, con su puntero y su serialización— es trabajo real que la plataforma ya hizo.

flowchart LR
A[color azul] -->|pushState| B[color azul y talla m]
B -->|pushState| C[color azul talla m pagina 2]
C -.atras.-> B
B -.atras.-> A
A -.adelante.-> B
style A fill:#89b4fa,color:#11111b
style B fill:#a6e3a1,color:#11111b
style C fill:#cba6f7,color:#11111b

La consecuencia de diseño es que tú decides qué merece una entrada en esa pila, y ahí entra la higiene del historial. Al escribir en la URL eliges entre dos operaciones. pushState empuja una entrada nueva: el usuario podrá volver a la anterior con el botón atrás. replaceState reemplaza la entrada actual sin crecer la pila: el cambio no deja rastro que deshacer. La regla es de intención: usa pushState para cambios que el usuario esperaría poder deshacer —aplicar un filtro relevante, cambiar de pestaña, pasar de página— y replaceState para actualizaciones continuas que no merecen una entrada cada una —teclear en un buscador, arrastrar un deslizador, mover un mapa—.

// cambio relevante: el usuario querria poder deshacerlo con el boton atras
function aplicarFiltro(clave: string, valor: string) {
  const p = new URLSearchParams(location.search);
  p.set(clave, valor);
  p.set('page', '1');                          // un filtro nuevo reinicia la pagina
  history.pushState(null, '', `?${p}`);        // deja un punto de retorno
}

// cambio de alta frecuencia: no debe ensuciar la pila con una entrada por evento
function moverDeslizador(valor: number) {
  const p = new URLSearchParams(location.search);
  p.set('precio', String(valor));
  history.replaceState(null, '', `?${p}`);     // reemplaza, no empuja
}

Deep linking como característica de producto

Reunidas las tres afordancias, emerge algo mayor que la suma: el deep linking como característica de producto. Un panel de control filtrado, un informe con un rango de fechas concreto, una vista de mapa centrada en un punto, un hilo abierto por una pestaña específica: todos se vuelven enlaces que un equipo comparte en un chat, incrusta en un documento o pega en un ticket. Lo que para el usuario es “mándame ese enlace” es, por dentro, estado serializado en la URL, y ninguna otra clase de estado habilita esa colaboración sin construir infraestructura a medida. La compartibilidad deja de ser una casilla técnica y se convierte en una vía por la que tu producto se difunde solo.

// compartir es leer la URL actual: el estado ya esta serializado ahi
async function compartirVista() {
  const url = location.href;                   // la vista entera, sin serializar nada extra
  if (navigator.share) await navigator.share({ url });
  else await navigator.clipboard.writeText(url);
}

Lo revelador de ese fragmento es lo poco que hace: compartir no exige recolectar el estado disperso por varios useState ni serializarlo a un formato propio, porque el estado navegable ya está serializado en location.href. Cuando la vista vive en la URL, “compartir” es leer una cadena que ya existe; cuando vive en memoria, “compartir” es un proyecto de serialización a medida que casi nadie acomete. La diferencia entre ambas realidades es exactamente la diferencia de haber ubicado bien el estado desde el principio.

Hay dos dividendos que redondean el argumento. El primero es el SSR: el servidor no ve tu store ni tu useState, porque se ejecuta antes de que el navegador hidrate nada, pero sí ve la URL, porque llega en la petición. Si los filtros viven en la URL, la página se sirve ya filtrada, sin parpadeo ni salto de contenido; si viven en memoria de cliente, el servidor pinta la vista por defecto y hay que corregirla tras hidratar, con el consiguiente destello. El segundo es la analítica: como cada filtro, búsqueda y pestaña queda escrito en una URL, tu herramienta de medición los captura gratis, sin instrumentar un evento por interacción.

La estabilidad del enlace: un contrato hacia el pasado

Compartir tiene una cara que casi nunca se anticipa: en el instante en que un usuario pega tu URL en un documento, un chat o un correo, esa URL se convierte en una interfaz pública con un contrato implícito de permanencia. El enlace vivirá en sitios que no controlas y se abrirá dentro de meses o años. A partir de ahí, el formato de tus search params ya no es un detalle interno que puedes refactorizar a voluntad: renombrar q a query, cambiar el separador de una lista o alterar el significado de un valor rompe, en silencio, todos los enlaces que alguien compartió antes del cambio.

Esto reencuadra el diseño de los parámetros como diseño de API, con las mismas obligaciones. Elige nombres de parámetros estables y descriptivos desde el principio, porque cambiarlos después es un cambio incompatible. Cuando la evolución sea inevitable, no borres el parámetro viejo: acéptalo en el parseo y redirígelo o tradúcelo al nuevo, igual que mantendrías una ruta antigua con una redirección permanente. Y prefiere siempre una URL canónica —una sola forma textual por estado— para que los enlaces compartidos, la caché y la analítica coincidan en lugar de multiplicarse en variantes.