GitHub, uç bir durumu ele almak için GitHub Copilot uygulamasındaki çekme isteği görüntüleme arayüzünü yeniden oluşturdu: 2.200 dosya, bir milyondan fazla değişen satır ve 400’den fazla satır içi inceleme yorumu içeren bir çekme isteği. Amaç yalnızca büyük farkların görüntülenmesini hızlandırmak değil, konuşmanın kendisi belgeye değişken boyutlar ekledikten sonra kaydırma ve inceleme işlemlerini kullanılabilir tutmaktı.
Büyük farklar için geleneksel arayüz, yalnızca görüntü alanının yakınındaki görünür öğeleri tutmak ve kaydırma sırasında DOM öğelerini yeniden kullanmak anlamına gelen sanallaştırmaya dayanır. Her öğe yüksekliği bilinen bir kod satırı olduğunda bu model görece kolay başarılı olur. Ancak yorumlar bu özelliğe sahip değildir; yükseklikleri Markdown sarmalanmasına, <details> bölümlerinin açılmasına, yanıt düzenleyicisinin görünmesine, görsellere, önerilen değişikliklere ve farklı etkileşim durumlarına göre değişir.
Tek bir yükseklik tablosu yerine iki düzen
GitHub, konumlar ve yükseklikler için önceden hesaplamalar kullanan ve bir yorum değiştiğinde yeniden oluşturulmayan sabit bir kod satırı düzenini korudu. Buna karşılık yorumları, yanıt düzenleyicilerini ve dinamik blokları ayrı bir dizine yerleştirdi. Her blokta dosya, satır ve tarafla ilişkilendirilmiş sabit bir anahtarın yanı sıra içerik parmak izi, açık bölümlerin durumu ve son ölçüm genişliği bulunuyor.
Ölçülen yükseklik, ölçümler geçerli olduğunda kullanılıyor; parmak izi ve genişlik uyumlu kaldığında önbelleğe alınmış değer kullanılıyor; aksi takdirde arayüz geçici bir tahmin kullanıyor. Böylece tek bir yorumun genişlemesi milyonlarca satırın düzeninin yeniden hesaplanmasına yol açmıyor.
Kaydırma yolunun dışında ölçüm
GitHub, her blok için ayrı bir ResizeObserver kullanan ve ölçümü doğrudan düzene yazan ilk tasarımdan vazgeçti. Bu model, düzen değişikliğinin gözlemi yeniden başlatması nedeniyle geri besleme döngüsü oluşturabilir; ayrıca maliyeti oluşturulan blokların sayısıyla artar.
Şirketin kullanıma sunduğu tasarım, boşta kalma aralıklarına ve kaydırma sona erdikten sonraki zamana bağlı tek bir ölçüm döngüsü kullanıyor. Genellikle yalnızca görüntü alanının yaklaşık 2.400 pikseli içindeki bloklar ölçülüyor; uzaktaki bloklar yaklaşana kadar tahminlerinde bırakılıyor. Görünür öğelerin ölçümleri, tekrarlanan yeniden akış işlemlerini önlemek için toplu olarak okunuyor.
Gözlemciler, görselin yüklenmesi veya yanıt düzenleyicisine yazı yazılması gibi değişiklikleri izlemek için varlığını sürdürüyor; ancak yüksekliği doğrudan değiştirmek yerine bloğu ölçüm döngüsünün yeniden okuması için işaretliyor. İstisna, bölümün veya yanıt düzenleyicisinin açılması gibi görünür bir blokta kullanıcı tarafından gerçekleştirilen değişikliktir; bu durumda aynı çerçevede tek bir eşzamanlı düzeltme uygulanabilir ve yorumun genişlemesiyle altındaki kodun hareketi arasında görünür bir adım oluşması önlenir.
Okuma konumunu kaybetmeden düzeni düzeltme
Gerçek yükseklik tahminden farklı olduğunda arayüz, konumu yalnızca piksel sayısına göre düzeltmiyor. Kullanıcının okumakta olduğu öğenin (bir satır veya yorum bloğu) kimliğini ve öğe içindeki ofseti koruyor, ardından yükseklik farklarını uygulayıp aynı öğenin konumunu yeniden hesaplıyor. Böylece sabitlenen öğe yaklaşık olarak aynı yerde kalıyor.
Düzeltmeler genellikle kullanıcı kaydırırken veya momentum devam ederken yapılmıyor; ekranın altındaki içerikten kaynaklanan değişiklikler de görünümü hareket ettirmek için kullanılmıyor. Ekip, panel genişliğinin değiştirilmesinden kaynaklanan programatik kaydırmanın kullanıcı kaydırması olarak kabul edildiği ve bunun düzeltmenin kaybolmasına ve okunan dosyanın kaymasına yol açtığı bir hatayla karşılaştı. Bu sorun, kullanıcı etkileşimi ile arayüzün kendisinin neden olduğu değişikliklerin birbirinden ayrılmasıyla çözüldü.
Veri akışı ve otomatik çalışan testler
Yanıt yalnızca sanallaştırmaya dayanmıyor. Farkların yapısı ve dosya verileri önce gönderiliyor; böylece belgenin geri kalanı yüklenirken dosya ağacı ve meta veriler görüntülenebiliyor. Sözdizimi vurgulama ve ayrıntılı Markdown oluşturma gibi işlemler ise öğeler görüntü alanına yaklaşana kadar erteleniyor. Arayüz ayrıca yakın zamanda kullanılan son birkaç farkı geçici olarak tutuyor ve bellek tüketimini azaltmak için bunun ötesindekileri temizliyor.
Yalnızca derin kaydırma sırasında ortaya çıkan kusurları tespit etmek için GitHub, oluşturulan satır ve blokların sayısını, çerçeve süresini, kaydırma düzeltmelerinin boyutunu, gözlemci sızıntılarını ve doldurulmamış boşlukların varlığını izleyen kalıcı ölçüm sinyalleri ve otomatik testler ekledi. Ekip, bölümlerin açılması, yanıt düzenleyicilerinin çalıştırılması, pencere boyutunun değiştirilmesi ve büyük bir dosya listesi içinde gezinme gibi durumlarla birlikte masaüstü uygulamasında ve gerçek görüntüleme motoru altında otomatik akışlar çalıştırdı.
Bu tasarım neden önemli?
Açıklanan sonuç, bir milyon satır ve yüzlerce yorum içeren bir çekme isteğinin sıradan bir çekme isteği gibi davranmasıdır: yorumlar iç içe bir kaydırma çubuğunun içinde kırpılmak yerine tamamen görüntüleniyor, bir bölümün genişletilmesi altındaki kodu rastgele sıçramalar olmadan hareket ettiriyor ve çekme isteğine geri dönüldüğünde okuma konumu korunabiliyor. En önemli mühendislik değeri, GitHub’ın tüm içeriği tek tip hale getirmeye çalışmaması; bunun yerine belirlenebilir kısmı hızlı tutup boyutu görüntülenmeden önce bilinemeyen içerikten ayırmasıdır.
Bununla birlikte metin, tüm büyük çekme isteklerinin anlama veya risk yönetimi açısından incelemesinin kolaylaştığını iddia etmiyor. Ele alınan konu, görüntüleme arayüzünün performansı ve ölçüm ile değişim sırasındaki davranışıdır. Ayrıca sonuçlar GitHub Copilot uygulaması ve dahili tasarımıyla bağlantılıdır; bellek tüketimi veya farklı cihazlar ve motorlar arasındaki performans göstergeleri hakkında bağımsız rakamlar sunulmamaktadır.