GitHub rehace la vista de pull requests de su app Copilot para diffs de un millón de líneas

GitHub ha reescrito la superficie de diff de la app GitHub Copilot para que aguante pull requests enormes. La prueba de esfuerzo la hicieron con un PR open source real: 2.200 archivos, más de un millón de líneas modificadas y más de 400 comentarios de revisión anclados a líneas concretas. El objetivo era que la vista siguiera respondiendo al hacer scroll con todo eso cargado encima.

Los PR apilados sirven para trocear el trabajo en cambios pequeños, pero hay refactors y migraciones que no se pueden partir sin romper cosas, y acaban aterrizando en un solo PR que además engorda con la conversación de revisión.

Un diff grande de solo código tiene una solución conocida: virtualizar. Se montan únicamente las filas visibles y un margen pequeño, y esos mismos nodos del DOM se reciclan mientras el usuario baja. Aunque el PR tenga un millón de líneas, en la página nunca hay más de un centenar de filas reales. Para que la ilusión se sostenga hace falta geometría: la altura de la barra de scroll es la suma de todas las filas, y la posición de la fila N es la suma de las de arriba. Si cada fila es una línea de código con un tamaño de fuente fijo, esa tabla se calcula entera antes de pintar y no cambia nunca. Ese contrato, todo conocido antes del primer pintado, sostiene el visor: un renderizador imperativo de filas recicladas en lugar de un componente por fila, geometría en typed arrays, documentos de diff que llegan del backend con la estructura primero y una API de scroll que salta a la fila exacta.

El problema son los comentarios

Un hilo de revisión rompe ese contrato. Su altura no se sabe hasta que se dibuja, porque depende de cómo pliegue el markdown según el ancho, de los bloques desplegables, del cuadro de respuesta que crece al escribir, de los diffs de cambio sugerido, de las reacciones y de las imágenes que aún no han cargado. Reservar un hueco fijo estimado falla por los dos extremos: sobra espacio en la mayoría de comentarios y falta en los caros, que acaban recortados o con su propio scroll anidado. Y medir la altura real después del pintado para corregir la tabla mueve todo lo que hay debajo mientras el usuario ya está bajando: un salto de scroll, y en un PR grande, bien grande.

Dos geometrías en la misma página

La salida fue dejar de forzar una única geometría. La altura del documento se parte en dos dominios. El código mantiene el mundo determinista de siempre, con sus sumas de prefijos exactas, y no se recalcula cuando un comentario cambia de tamaño. Los bloques dinámicos, es decir hilos, borradores y cajas de respuesta, se identifican por lo que son y no por dónde están: llevan una clave estable que sobrevive a la carga de su contenido y van anclados a archivo, línea y lado, no a una coordenada en píxeles, de modo que un reflujo no los pierde. Guardan además una huella de todo lo que puede alterar su altura (el contenido, si un desplegable está abierto, si hay un compositor activo) y el ancho con el que se midieron la última vez.

Encontrar los fallos tampoco era cuestión de mirar. Aparecían bajo carga, en un motor concreto y en una posición de scroll concreta. El equipo definió qué significaba un estado sano, instrumentó la vista para comprobarlo y dejó corriendo el ciclo de cambiar, medir y mejorar sin nadie delante.

Queda por ver si estas técnicas se quedan dentro de Copilot o salen al resto de las vistas de diff de GitHub, que es donde le tocarían a la mayoría de la gente que revisa código cada día.