GitHub Copilot App: So werden riesige Pull Requests flüssig renderbar

Riesige Pull Requests sind der Albtraum jedes Reviewers: Broad Refactors und Migrationen lassen sich oft nicht sinnvoll aufteilen, und die Review-Konversation macht den Diff mit jeder Antwort größer. Das GitHub-Team hat die Pull-Request-Ansicht der Copilot App deshalb von Grund auf neu gebaut - und den härtesten Testfall gesucht, den es fand: einen Open-Source-PR mit 2.200 Dateien, über einer Million geänderter Zeilen und mehr als 400 Inline-Kommentaren.

Warum Kommentare das Problem sind

Reine Code-Diffs per Virtualisierung schnell zu rendern ist Standard: Nur sichtbare Zeilen mounten, DOM-Elemente recyclen. Jede Zeile hat eine bekannte Höhe, die Geometrie lässt sich vorab exakt berechnen. Kommentare zerstören diese Garantie: Markdown-Umbrüche, aufklappbare Bereiche, Reply-Boxen und nachladende Bilder machen die Höhe erst zur Renderzeit bekannt - und sie ändert sich danach weiter.

Zwei getrennte Geometrien

Die Kernidee des Designs ist, die Höhenberechnung des Dokuments in zwei unabhängige Domänen aufzuteilen:

• Code-Geometrie: Deterministisch, exakt, als Prefix-Summen in Typed Arrays vorberechnet. Wird nie neu gebaut, wenn ein Kommentar seine Größe ändert
• Dynamische Block-Geometrie: Jeder Kommentar-Thread ist ein Block mit stabilem Key, an Datei und Zeile verankert statt an Pixeln. Ein Fingerprint aus Inhalt und Zustand entscheidet, ob eine gemessene Höhe noch gültig ist

Messen ohne Jank

Der erste Entwurf - ein ResizeObserver pro Block, der Höhen direkt in das Layout zurückschreibt - wurde verworfen: genau diese Rückkopplungsschleife machen große virtualisierte Oberflächen träge. Stattdessen fährt ein einzelner Idle- und Scroll-gesteuerter Messdurchlauf:

• Läuft nur wenn der Scroll-Bereich sich beruhigt hat, nie pro Scroll-Frame
• Beschränkt auf Blöcke in Viewport-Nähe (etwa 2400px), also O(Viewport) statt O(Dokument)
• Pro Frame höchstens ein synchroner Commit, niemals während des Scrollens
• Scroll-Anchoring korrigiert nach Identität, damit der Viewport beim Nachmessen nicht springt

Das Ergebnis: Ein Millionen-Zeilen-Diff mit hunderten Threads scrollt wie ein normaler PR, Kommentare rendern vollständig statt in einer geclippten Scrollbox, und das Aufklappen eines Bereichs verschiebt nur den Code darunter. Wer regelmäßig große Reviews macht, sollte den Worst-Case-PR in der eigenen Pipeline einmal ausprobieren.

Mehr dazu: GitHub Blog