nota técnica

Enlaces que se pueden compartir en una interfaz de ventanas

28 de agosto de 2026 · sobre la navegación de este mismo sitio

Este sitio finge ser un escritorio. Las secciones son ventanas que se abren, se enfocan, se minimizan y se cierran, y varias pueden estar abiertas a la vez.

Eso trae un problema que las páginas normales no tienen: no hay nada que copiar y pegar. Si alguien quiere mandarte la sección de contacto, lo único que puede mandar es la portada y una instrucción de dónde hacer clic. Se resolvió con rutas en el hash de la URL y sin ninguna librería. Las decisiones interesantes no fueron de código.

La URL representa la ventana enfocada, no todo lo que hay abierto

Usualmente, una forma de resolver este problema es serializar el estado completo de nuestro escritorio falso, es decir, las ventanas abiertas, el orden, las minimizadas y su ubicacion.

Esto tiene dos problemas principales: La URL se vuelve ilegible, y nadie quiere de verdad que le restauren el escritorio de otro usuario.

Así que la URL dice una sola cosa: cuál es la aplicación relevante ahora. El resto —apilamiento, minimizado, posición— es estado transitorio de interfaz y se queda fuera.

Historial: lo último es lo que se guarda

Con varias ventanas abiertas, hacer clic en una la enfoca. Si cada uno de esos clics creara una entrada de historial, el botón de atrás quedaría inservible después de treinta segundos de uso. 

abrir una app desde el menú   → push    crea historial
hacer clic en una ventana     → replace no crea historial

La distinción no es técnica, es de intención: navegar a algo es un acto deliberado, mirar otra ventana no lo es.

El nombre público de una ruta no es el identificador interno

Las rutas viven en un solo archivo que las traduce al identificador interno de cada ventana. Parece burocracia hasta que sirve.

La trampa que nos costó encontrar

Hay dos manejadores de clic sobre la misma raíz: uno abre ventanas, otro escribe la ruta. Los dos empiezan igual, comprobando si el clic vino de un elemento marcado como disparador de apertura.

Al final del segundo hay una regla general: si el clic ocurrió dentro de una ventana, la ruta pasa a ser la de esa ventana. Esa regla es la que mantiene la URL sincronizada cuando enfocas algo.

Entonces escribimos un enlace normal, con su href y nada más, para llevar de una sección a su detalle. El resultado fue desconcertante: la ventana de detalle se abría, y acto seguido la URL volvía a la sección de origen. Como la nueva ventana aparecía detrás, parecía que el clic no había hecho nada. 

clic en el enlace
  → el hash cambia y la ventana de detalle se abre
  → el manejador general ve un clic dentro de la ventana de origen
  → reescribe la ruta a la de origen

La corrección cabe en un atributo: el enlace lleva también la marca de disparador, y entonces el primer manejador lo atiende y sale antes de llegar a la regla general.

Lo que se hizo después importa más que la corrección

Quedó anotada en el documento de traspaso del proyecto, en una sección de trampas conocidas, con el síntoma exacto —parece que no pasó nada— y la causa.

Porque el siguiente enlace de ese tipo va a tropezar igual, y el problema real no es que el fallo ocurra: es perder otra tarde volviendo a diagnosticarlo. Un atajo o una trampa que se marca es una decisión; la que se calla es un descuido esperando a otro.

Prevenir el bucle

La regla es esta:

acción del usuario   → escribe la ruta → abre y enfoca
evento de historial  → abre y enfoca      (no escribe la ruta)

Si el manejador del atrás del navegador vuelve a escribir la ruta, genera otro evento, que vuelve a escribir. Restaurar estado y provocarlo tienen que ser dos funciones distintas.

Lo que no se hizo

Sobre esto último conviene ser honesto: los enlaces con hash sirven para compartir y para volver, no para posicionar. Para un buscador todo esto sigue siendo un solo documento. Por eso esta nota que estás leyendo no vive en una ventana, sino en su propia página con su propia dirección.