Transiciones concurrentes: mantener lo viejo mientras carga lo nuevo

Cuando alguien pulsa una pestaña cuyo contenido tarda seiscientos milisegundos en llegar, la interfaz tradicional solo dispone de dos gestos y los dos son malos. Puede desmontar lo que había y poner un esqueleto, con lo que destruye información todavía útil, provoca un salto de maquetación y castiga con una pantalla vacía a quien tenía buena conexión y habría esperado sin enterarse. O puede quedarse bloqueada esperando el dato, con lo que la aplicación deja de responder y el usuario duda de si su pulsación se registró. Las transiciones concurrentes rompen esa disyuntiva con un cambio de modelo, no con un truco de presentación: separan las actualizaciones en dos clases de urgencia y permiten que el motor trabaje en la pantalla futura sin desmontar la presente, manteniendo la vieja completamente viva mientras la nueva se construye en segundo plano. El resultado no es solo estético. Es una forma distinta de repartir el tiempo de la máquina entre lo que el usuario acaba de hacer y lo que ese acto implica.

Dos urgencias, dos árboles

La observación de partida es que no todas las actualizaciones de estado tienen el mismo contrato con la persona. Cuando alguien escribe una letra, el cursor y el carácter deben aparecer en el siguiente fotograma sin excepción, porque una latencia de cien milisegundos en la respuesta del teclado se percibe como una avería. Cuando esa misma letra provoca la carga de una lista filtrada, nadie espera que la lista aparezca instantáneamente. Son dos actualizaciones disparadas por el mismo evento con dos exigencias temporales que difieren en un orden de magnitud, y un sistema que las trate igual tendrá que elegir entre dos malas opciones: bloquear el teclado esperando la lista, o vaciar la lista para no bloquear el teclado.

// Marcar la parte no urgente permite que el teclado no espere a la lista.
const [texto, setTexto] = useState("")
const [consulta, setConsulta] = useState("")
const [pendiente, empezarTransicion] = useTransition()

function alEscribir(v: string) {
  setTexto(v)                                   // urgente: se ve ya
  empezarTransicion(() => setConsulta(v))       // no urgente: puede esperar
}
// Mientras la transicion trabaja, la lista antigua sigue en pantalla,
// visible y utilizable, y pendiente vale true para poder atenuarla.

La clave del mecanismo, y lo que lo distingue de cualquier retardo o antirrebote, es que existen dos árboles a la vez. El motor conserva el árbol actual montado y pintado mientras construye una versión nueva en memoria a partir del estado nuevo; si durante esa construcción llega otra entrada urgente, el trabajo en curso se descarta o se reanuda más tarde y la entrada urgente se atiende de inmediato. El árbol nuevo solo sustituye al viejo cuando está completo. Por eso la técnica no es una animación ni un aplazamiento: es una reorganización del reparto del tiempo de cómputo entre dos versiones simultáneas del mismo estado.

flowchart TD
A[pulsacion del usuario] --> B[actualizacion urgente]
A --> C[actualizacion marcada como transicion]
B --> D[se pinta en el fotograma siguiente]
C --> E[render del arbol nuevo en segundo plano]
E --> F[el arbol viejo sigue montado y visible]
E -->|llega otra entrada urgente| G[descartar trabajo y reempezar]
E -->|termina| H[intercambiar arbol viejo por nuevo]
style D fill:#a6e3a1,color:#11111b
style H fill:#a6e3a1,color:#11111b

Esta arquitectura impone una condición que conviene entender porque explica muchas reglas que de otro modo parecen arbitrarias. Si el motor puede empezar un render, abandonarlo a medias y volver a empezarlo, entonces la fase de render no puede tener efectos observables fuera de sí misma. Nada de escribir en una variable de módulo, nada de disparar una petición, nada de mutar un objeto compartido, nada de leer un valor que pueda haber cambiado entre dos intentos. La pureza del render deja de ser una recomendación de estilo y pasa a ser el requisito que hace posible la interrupción. Un componente impuro no produce un aviso: produce un fallo intermitente que aparece solo cuando el render que dejó a medias la basura fue precisamente el descartado.

De esa misma exigencia se deriva la regla que gobierna la lectura de estado externo, y que es la fuente de los defectos más difíciles de diagnosticar de todo el modelo. Si un componente lee directamente de una fuente mutable ajena al motor, una caja de estado global, un almacén de un tercero, el objeto de sesión del navegador, nada garantiza que los dos intentos de render lean el mismo valor, y el resultado puede ser un árbol construido con la mitad de los datos viejos y la mitad de los nuevos. Es el fenómeno que se conoce como desgarro, y su nombre está tomado directamente de la literatura de memoria compartida, donde describe la lectura de una palabra mientras otro hilo la escribe. Que reaparezca aquí, en un entorno de un solo hilo, es una confirmación elegante de la tesis de este nivel: el problema nunca fue el paralelismo, fue tener dos versiones del mundo vivas a la vez y no decidir cuál manda.

El estado pendiente como dato de primera clase

Mantener la pantalla vieja resuelve la pérdida de información y crea un problema nuevo, porque durante la transición la interfaz está mintiendo: muestra unos datos y la persona ya pidió otros. El puente entre ambas cosas es el estado pendiente, y tratarlo como un simple indicador de carga desperdicia casi todo su valor. Lo que expresa no es que algo se esté cargando, sino que lo visible corresponde a una intención ya superada. Esa afirmación tiene consecuencias visuales concretas y bastante distintas de las de un esqueleto.

Conviene además distinguir el estado pendiente de la carga inicial, porque comparten indicador en muchas implementaciones y no comparten significado. La carga inicial ocurre cuando no hay nada que mostrar y el esqueleto es la respuesta correcta, porque comunica la forma de lo que vendrá y reserva el espacio que ocupará. El estado pendiente ocurre cuando sí hay algo que mostrar y la respuesta correcta es conservarlo. Usar el mismo componente para ambos casos produce la peor combinación posible, que es destruir contenido útil para pintar un armazón que la persona ya ha visto. La distinción es fácil de codificar, basta con preguntar si existen datos previos para la unidad de coherencia actual, y su efecto sobre la percepción es desproporcionado respecto a lo que cuesta.

Hay un detalle de percepción que casi nadie mide y que decide si toda esta maquinaria mejora algo. La ventaja de mantener la pantalla vieja no consiste en que el usuario siga leyendo el contenido antiguo, que rara vez le interesa; consiste en que la pantalla no salta, en que el foco no se pierde, en que la posición del desplazamiento se conserva y en que la sensación de continuidad no se rompe. Son exactamente los factores que se degradan cuando un contenedor se vacía y se vuelve a llenar, y son también los que ninguna métrica de tiempo de respuesta refleja. Por eso una transición puede ser objetivamente más lenta que un esqueleto, porque no muestra nada nuevo hasta el final, y aun así puntuar mejor en cualquier prueba con personas reales.

// Consumidor que no controla el origen: difiere el valor recibido
// y deduce el estado pendiente comparando lo diferido con lo actual.
function Resultados({ consulta }: { consulta: string }) {
  const diferida = useDeferredValue(consulta)
  const obsoleta = diferida !== consulta
  const items = useResultados(diferida)   // la parte cara del arbol

  return (
    <section aria-busy={obsoleta} data-obsoleta={obsoleta}>
      <Lista items={items} />
    </section>
  )
}

// La senal semantica va en el atributo, no solo en la opacidad:
// un lector de pantalla debe enterarse de que el contenido esta cambiando.

Ese último detalle no es accesorio. Atenuar un bloque comunica la obsolescencia a quien ve la pantalla y no comunica absolutamente nada a quien la escucha, de modo que una técnica pensada para mejorar la percepción puede empeorar la experiencia de una parte de los usuarios si se implementa solo con opacidad. El atributo que declara que una región está ocupada, junto con una región de anuncio cortés que informe del cambio cuando termine, es lo que convierte la transición en una mejora universal y no en una mejora visual. Y como el estado pendiente ya es un dato explícito, exponerlo por esas dos vías no cuesta ningún trabajo adicional: es la misma variable leída dos veces.

Dónde la técnica no ayuda o estorba

Conviene delimitar el alcance con la misma energía con la que se ha defendido la técnica, porque su aplicación indiscriminada produce interfaces peores. El primer límite es que una transición no acelera nada: si el dato tarda tres segundos, seguirá tardando tres segundos, y durante ese tiempo la pantalla mostrará información obsoleta sin decirlo con suficiente claridad. A partir de cierto umbral, alrededor del segundo, el esqueleto honesto comunica mejor que la atenuación, porque nadie mantiene la atención sobre un contenido a medio atenuar durante tanto rato. La técnica está diseñada para el rango que va de los cien a los ochocientos milisegundos, que es donde el parpadeo molesta y la espera todavía no exige explicación.

Existe también un límite de composición que se descubre tarde y duele. Si dentro del subárbol que se está construyendo aparece un componente que suspende y no está cubierto por un límite adecuado, el motor puede verse obligado a mostrar el respaldo de carga más cercano, y entonces la transición degenera precisamente en el parpadeo que quería evitar, con el agravante de que ahora el parpadeo ocurre más tarde y por tanto sorprende más. Colocar los límites de suspensión con criterio deja de ser una cuestión de organización y pasa a ser parte del diseño de la transición: cada límite es una frontera que declara hasta dónde puede mantenerse el contenido antiguo y a partir de dónde se acepta mostrar un hueco.

El segundo límite es la naturaleza de la acción. Una transición sirve para navegar, filtrar y cambiar de vista, es decir, para operaciones de lectura donde el estado anterior sigue siendo una respuesta razonable a la pregunta anterior. No sirve para confirmar una escritura, porque ahí el usuario necesita saber si su acción tuvo efecto y mantener la pantalla previa comunica justo lo contrario. Tampoco sirve cuando el contenido viejo puede inducir a error de forma grave, como en un panel de precios, una dosis o un saldo, donde mostrar un valor superado con apariencia normal es peor que mostrar un hueco. Y no aporta nada cuando el cambio es local y barato, donde toda la maquinaria solo añade latencia de coordinación.