Remote-Driven Arayüzlerin Sessiz Motoru: Navix

Bu raportajda sorular bana, cevaplar Claude'a ait. Claude projeyi herhangi bir dokümantasyon okumadan, yalnızca kaynak kodu inceleyerek yanıtladı. Ortaya çıkan bilgiyi birlikte şekillendirdik.

Navix, TV, set-top box ve benzeri uzaktan kumanda ile kullanılan ekranlar için geliştirilmiş bir navigasyon kütüphanesidir. React ve Flutter için iki ayrı implementasyonu vardır; ikisi de aynı çekirdek fikir üzerine kurulu.

Temel sorun şu: web ve mobil uygulamalar için dokunmatik veya fare odaklı navigasyon varsayılan olarak gelir. Ama bir smart TV remote'unda sadece yön tuşları, enter ve back vardır. Bu ortamda hangi elemanın odakta olduğunu, bir tuşa basıldığında odağın nereye geçeceğini ve ekrandaki hangi bileşenlerin bu karardan haberdar olacağını tamamen elle yönetmek gerekir. Navix bunu üstlenir.

Bunun için bir ağaç yapısı kurar. Her navigasyon bileşeni bu ağaca bir düğüm olarak katılır; parent-child ilişkisi, bileşenlerin arayüzdeki yerleşim sırasını takip eder. Bir tuşa basıldığında olay önce odaktaki en derin düğüme ulaşır, eğer o düğüm işlemezse parent'ına, ondan parent'ına... böyle köke kadar çıkar.

Odak her zaman ağaçta tek bir aktif yol üzerindedir. InputManager katmanı ise ham klavye eventlerini left, right, enter, back, play_pause gibi platforma bağımsız aksiyon isimlerine dönüştürür. Uzun basış ve çift basış gibi girdi tipleri de burada yönetilir.

TV benzeri arayüzlerde ilk akla gelen çözüm genellikle şudur: onKeyDown yakala, focused state'i kendine göre yönet. Bu yaklaşım küçük ekranlarda tutunur, ama birden fazla iç içe navigasyon bölgesi olduğu anda dağılır. Hangi bileşen odakta? Bir liste içinde başka bir liste varsa tuş olayı kime gitmeli? Bir modal açıldığında alttaki her şeyin odağa kapalı olduğundan nasıl emin olunur? Ekrandan bir bileşen kaldırıldığında odak nereye geçmeli? Bunları her bileşende ayrı ayrı çözmek; hem tekrar eden kod hem de birbirini kıran edge case'ler demektir.

Navix odak yönetimini ağaç yapısına bağlar. Her bileşen sadece kendi içinde ne yapacağını bilir; geri kalanını ağaç çözer. Bunun pratik karşılıkları şunlardır:

• Focus trap otomatik çalışır. Bir dropdown veya video oynatıcı paneli açıldığında ağaçtaki başka hiçbir düğüm odak alamaz. Bunu elle implement etmek yerine kütüphane davranış olarak sunar.
• Bileşen kaldırıldığında odak kaybolmaz. Ağaç, en yakın geçerli kardeşe ya da parent'a otomatik geçer.
• Klavye girdisi soyutlanmıştır. Samsung, LG, Apple TV remote keyCode'ları... hepsi InputManager'da ortak isimlere dönüşür. Uygulama kodunun platformdan haberi olmaz.
• Hazır bileşenler: yatay/dikey liste, sayfalanmış grid, expandable, dropdown, stepper, scroll, video oynatıcı için MultiLayer.
• React ve Flutter'da aynı model. İki platforma birden hedef alan ekiplerde temel kavramlar aktarılabilir.

Flutter'ın kendi built-in çözümü vardı. Ancak bu çözüm özünde tab ile bir sonraki elemana atlama mantığına dayanıyordu; odağın nereye gideceği her zaman öngörülebilir değildi ve istenmeyen zıplamalar kaçınılmaz oluyordu. Daha hassas bir policy tanımlamak mümkündü, ama bunun bedeli her bileşen için ayrı ayrı yazılmış onlarca satır konfigürasyondu.

Navix'in hiyerarşik yapısında ise yön, yapıdan doğrudan okunur. Kumandadan right tuşuna basıldığında odağın nereye gideceği, ağaçtaki yerleşimden zaten bellidir. Dekoratif ögeler odak dışında tutulur, PaginatedList gibi bileşenler yüzlerce item arasında gezinmeyi herhangi bir ekstra kod gerektirmeden yönetir.