GitHub reconstruyó la interfaz de visualización de solicitudes de extracción en la aplicación GitHub Copilot para abordar un caso extremo: una solicitud de extracción con 2.200 archivos, más de un millón de líneas modificadas y más de 400 comentarios de revisión insertados. El objetivo no era solo acelerar la visualización de una diferencia grande, sino mantener el desplazamiento y la revisión utilizables después de que la propia conversación añadiera dimensiones variables al documento.
La interfaz tradicional para diferencias grandes se basa en la carga virtual, es decir, mantener cerca del área visible únicamente los elementos que se muestran y reutilizar elementos DOM durante el desplazamiento. Este modelo funciona con relativa facilidad cuando cada elemento es una línea de código de altura conocida. Pero los comentarios no tienen esta propiedad; su altura cambia según el ajuste de Markdown, la apertura de secciones <details>, la aparición del editor de respuestas, las imágenes, las modificaciones propuestas y los distintos estados de interacción.
Dos geometrías en lugar de una única tabla de alturas
GitHub mantuvo una geometría fija para las líneas de código, que utiliza cálculos previos de posiciones y alturas y no se reconstruye cuando cambia un comentario. En cambio, colocó los comentarios, los editores de respuestas y los bloques dinámicos en un índice independiente. Cada bloque tiene una clave estable vinculada al archivo, la línea y el lado, además de una huella del contenido, el estado de las secciones abiertas y el último ancho medido.
Se utiliza la altura medida cuando las mediciones son válidas, o un valor almacenado temporalmente mientras la huella y el ancho sigan siendo compatibles; de lo contrario, la interfaz utiliza una estimación provisional. De este modo, la expansión de un solo comentario no provoca el recálculo de la geometría de millones de líneas.
Medición fuera de la ruta de desplazamiento
GitHub abandonó un diseño inicial que dependía de un ResizeObserver independiente para cada bloque y escribía la medición directamente en el diseño. Este patrón puede crear un bucle de retroalimentación, porque el cambio del diseño vuelve a activar la supervisión, y su coste también aumenta con el número de bloques montados.
El diseño que la empresa lanzó utiliza un único ciclo de medición vinculado a los periodos de inactividad y al final del desplazamiento. Normalmente solo se miden los bloques situados a unos 2.400 píxeles del área visible, mientras que los bloques lejanos mantienen sus estimaciones hasta que se acercan. Las mediciones de los elementos visibles se leen en un solo lote para evitar operaciones repetidas de reflujo.
Los observadores siguen presentes para detectar cambios como la carga de una imagen o la escritura en el editor de respuestas, pero marcan el bloque para que el siguiente ciclo de medición vuelva a leerlo, en lugar de modificar directamente la altura. La excepción es un cambio provocado por el usuario en un bloque visible, como abrir una sección o un editor de respuestas; en ese caso se puede aplicar una única corrección síncrona en el mismo fotograma, lo que evita que aparezca un paso visible entre la expansión del comentario y el movimiento del código situado debajo.
Corregir el diseño sin perder la posición de lectura
Cuando la altura real difiere de la estimación, la interfaz no corrige la posición basándose únicamente en el número de píxeles. Conserva la identidad del elemento que está leyendo el usuario, ya sea una línea o un bloque de comentario, y determina el desplazamiento dentro de él; después aplica las diferencias de altura y vuelve a calcular la posición del mismo elemento. De esta manera, el elemento fijado permanece aproximadamente en el mismo lugar.
Normalmente no se realizan correcciones durante el desplazamiento o el impulso del usuario, ni se utilizan los ajustes derivados de contenido situado debajo de la pantalla para mover la vista. El equipo se encontró con un error cuando el desplazamiento programático provocado por un cambio en el ancho del panel se consideró un desplazamiento del usuario, lo que ocasionó la pérdida de la corrección y el deslizamiento del archivo que se estaba leyendo. Se solucionó separando la interacción del usuario de los cambios provocados por la propia interfaz.
Canal de datos y pruebas automatizadas
La capacidad de respuesta no depende únicamente de la carga virtual. La estructura de las diferencias y los datos de los archivos se envían primero para que el árbol de archivos y los metadatos aparezcan mientras se carga el resto del documento, mientras que tareas como el resaltado de sintaxis y la construcción detallada de Markdown se posponen hasta que los elementos se acercan al área visible. La interfaz también conserva temporalmente las últimas pocas diferencias utilizadas y elimina las que exceden ese límite para reducir el consumo de memoria.
Para detectar defectos que solo aparecen durante un desplazamiento profundo, GitHub añadió señales de medición permanentes y pruebas automatizadas que supervisan el número de filas y bloques montados, el tiempo del fotograma, el tamaño de las correcciones del desplazamiento, las fugas de observadores y la existencia de espacios sin rellenar. El equipo ejecutó flujos automatizados en la aplicación de escritorio y con el motor de renderizado real, con casos como abrir secciones, activar editores de respuestas, cambiar el tamaño de la ventana y navegar dentro de una lista de archivos grande.
¿Por qué importa este diseño?
El resultado anunciado es que una solicitud de extracción de un millón de líneas y cientos de comentarios se comporta como una solicitud normal: los comentarios se muestran completos en lugar de recortarse dentro de una barra de desplazamiento anidada, la expansión de una sección mueve el código situado debajo sin saltos aleatorios y es posible volver a una solicitud de extracción conservando la posición de lectura. Lo más importante desde el punto de vista de la ingeniería es que GitHub no intentó hacer que todo el contenido tuviera una misma naturaleza; mantuvo rápida la parte determinista y la separó del contenido cuyo tamaño no puede conocerse antes de mostrarlo.
Aun así, el material no afirma que todas las solicitudes de extracción grandes se hayan vuelto fáciles de revisar en cuanto a comprensión o gestión de riesgos. Lo que abordó fue el rendimiento y el comportamiento de la interfaz durante la medición y los cambios. Además, los resultados están vinculados a la aplicación GitHub Copilot y a su diseño interno, y no ofrecen cifras independientes sobre el consumo de memoria ni indicadores de rendimiento en distintos dispositivos y motores.