GitHub a reconstruit l’interface d’affichage des pull requests dans l’application GitHub Copilot pour gérer un cas extrême : une pull request comprenant 2 200 fichiers, plus d’un million de lignes modifiées et plus de 400 commentaires de révision intégrés. L’objectif n’était pas seulement d’accélérer l’affichage d’une grande différence, mais de maintenir le défilement et la révision utilisables lorsque la conversation elle-même ajoute des dimensions variables au document.
L’interface traditionnelle des grandes différences repose sur le chargement virtuel, c’est-à-dire le maintien des seuls éléments visibles près de la fenêtre d’affichage, avec réutilisation des éléments DOM pendant le défilement. Ce modèle fonctionne relativement facilement lorsque chaque élément est une ligne de code de hauteur connue. Mais les commentaires ne possèdent pas cette propriété : leur hauteur varie en fonction du retour à la ligne du Markdown, de l’ouverture des sections <details>, de l’apparition de l’éditeur de réponse, des images, des modifications proposées et des différents états d’interaction.
Deux géométries plutôt qu’un seul tableau de hauteurs
GitHub a conservé une géométrie fixe pour les lignes de code, qui utilise des calculs préalables des positions et des hauteurs et ne les reconstruit pas lorsqu’un commentaire change. En revanche, elle a placé les commentaires, les éditeurs de réponse et les blocs dynamiques dans un index indépendant. Chaque bloc possède une clé stable liée au fichier, à la ligne et au côté, ainsi qu’une empreinte du contenu, l’état des sections ouvertes et la dernière largeur mesurée.
La hauteur mesurée est utilisée lorsque les mesures sont valides, ou une valeur mise en cache lorsque l’empreinte et la largeur restent compatibles ; sinon, l’interface utilise une estimation temporaire. Ainsi, l’agrandissement d’un seul commentaire n’entraîne pas le recalcul de la géométrie de millions de lignes.
La mesure en dehors du chemin du défilement
GitHub a abandonné une conception initiale qui reposait sur un ResizeObserver indépendant pour chaque bloc et écrivait directement la mesure dans la mise en page. Ce modèle peut créer une boucle de rétroaction, car une modification de la mise en page relance l’observation, et son coût augmente également avec le nombre de blocs rendus.
La conception livrée par l’entreprise utilise un cycle de mesure unique lié aux périodes d’inactivité et à la fin du défilement. En général, seuls les blocs situés dans un rayon d’environ 2 400 pixels autour de la fenêtre d’affichage sont mesurés, tandis que les blocs éloignés conservent leurs estimations jusqu’à ce qu’ils s’en approchent. Les mesures des éléments visibles sont lues en une seule fois afin d’éviter des recalculs de mise en page répétés.
Les observateurs restent présents pour détecter des changements tels que le chargement d’une image ou la saisie dans l’éditeur de réponse, mais ils marquent le bloc afin que le cycle de mesure le relise, au lieu de modifier directement la hauteur. L’exception concerne un changement provoqué par l’utilisateur dans un bloc visible, comme l’ouverture d’une section ou d’un éditeur de réponse ; dans ce cas, une seule correction synchrone peut être appliquée dans la même frame, ce qui empêche l’apparition d’une étape visible entre l’agrandissement du commentaire et le déplacement du code situé en dessous.
Corriger la mise en page sans perdre la position de lecture
Lorsque la hauteur réelle diffère de l’estimation, l’interface ne corrige pas la position en se fondant uniquement sur le nombre de pixels. Elle conserve l’identité de l’élément lu par l’utilisateur, qu’il s’agisse d’une ligne ou d’un bloc de commentaire, et détermine son décalage interne, puis applique les différences de hauteur et recalcule la position du même élément. De cette manière, l’élément suivi reste approximativement au même endroit.
Les corrections ne sont généralement pas effectuées pendant le défilement ou l’inertie de l’utilisateur, et les ajustements résultant d’un contenu situé sous l’écran ne sont pas utilisés pour déplacer l’affichage. L’équipe a rencontré un bug lorsque le défilement programmatique provoqué par une modification de la largeur du panneau a été considéré comme un défilement de l’utilisateur, ce qui a entraîné la perte de la correction et une dérive du fichier consulté. Le problème a été résolu en séparant l’interaction de l’utilisateur des changements provoqués par l’interface elle-même.
Un pipeline de données et des tests automatisés
La réactivité ne repose pas uniquement sur le rendu virtuel. La structure des différences et les données des fichiers sont envoyées en premier afin que l’arborescence des fichiers et les métadonnées apparaissent pendant le chargement du reste du document, tandis que des opérations telles que la coloration syntaxique et la construction détaillée du Markdown sont différées jusqu’à ce que les éléments s’approchent de la fenêtre d’affichage. L’interface conserve également temporairement les dernières différences utilisées, en supprimant celles qui les dépassent afin de réduire la consommation mémoire.
Pour détecter les défauts qui n’apparaissent qu’au cours d’un défilement profond, GitHub a ajouté des signaux de mesure permanents et des tests automatisés qui surveillent le nombre de lignes et de blocs rendus, le temps par frame, l’ampleur des corrections de défilement, les fuites des observateurs et la présence d’espaces non remplis. L’équipe a exécuté des flux automatisés sur l’application de bureau et avec le moteur de rendu réel, dans des cas tels que l’ouverture de sections, l’activation d’éditeurs de réponse, le redimensionnement de la fenêtre et la navigation dans une grande liste de fichiers.
Pourquoi cette conception est-elle importante ?
Le résultat annoncé est qu’une pull request d’un million de lignes et de centaines de commentaires se comporte comme une pull request ordinaire : les commentaires sont affichés intégralement au lieu d’être tronqués dans une barre de défilement imbriquée, le développement d’une section déplace le code situé en dessous sans sauts aléatoires et il est possible de revenir à une pull request en conservant la position de lecture. L’idée d’ingénierie la plus importante est que GitHub n’a pas essayé de donner à tout le contenu une nature homogène ; elle a plutôt conservé la partie déterministe rapide et l’a séparée du contenu dont la taille ne peut pas être connue avant son affichage.
Cependant, l’article ne prétend pas que toutes les pull requests volumineuses sont devenues faciles à réviser du point de vue de la compréhension ou de la gestion des risques. Ce qui a été traité, c’est la performance et le comportement de l’interface pendant la mesure et les changements. Les résultats sont également liés à l’application GitHub Copilot et à sa conception interne, et ne fournissent pas de chiffres indépendants sur la consommation mémoire ou les indicateurs de performance selon les appareils et les moteurs différents.