JSON ağaç görünümü ve tablo görünümü: Hangisi hata ayıklamayı gerçekten hızlandırıyor?

Çoğu JSON görüntüleyicisi, ağaç görünümü (iç içe geçmiş, daraltılabilir, her satırda tek değer) ile tablo görünümü (satır ve sütunlar, elektronik tablo tarzı) arasında seçim yapma imkânı sunar. Bunlar aynı verinin iki farklı görünümü gibi göründüğünden, aracın varsayılan olarak açtığı seçeneği seçmek cazip gelebilir. Bu yanlış bir içgüdüdür — aslında bu iki görünüm, farklı veri yapıları ve farklı hata ayıklama görevleri için optimize edilmiştir ve iş için yanlış olanı seçmek size gerçek zaman kaybına mal olur.

Her bir görünümün asıl neye uygun olduğu

Ağaç görünümü, JSON’un gerçek yapısını yansıtır: her nesne ve dizi, daraltılabilir bir düğümdür; her yaprak değeri, anahtarının yanında kendi satırında yer alır. Aşağıdaki durumlarda bu doğru seçimdir:

Hata ayıklama yaptığınız şey yapının kendisiyse — derinlemesine iç içe geçmiş bir nesnenin neresinde bir değerin bulunduğunu bulmaya çalışıyorsanız veya bir alanın gerçekten var olup olmadığını doğrulamaya çalışıyorsanız.
Veriler düzensizse — aynı yanıt içindeki farklı nesneler farklı anahtar kümelerine, isteğe bağlı alanlara veya değişken iç içe geçme derinliklerine sahipse. Bir tablo bunu net bir şekilde gösteremez; ancak bir ağaç gösterebilir.
Belirli bir nesnenin hangi diziye ait olduğunu izlemek gibi, üst-alt ilişkilerini açıkça görmeniz gerekiyor.

Tablo görünümü, nesnelerden oluşan bir diziyi satırlara ve sütunlara düzleştirir; her anahtar için bir sütun bulunur. Bu, aşağıdaki durumlarda avantajlıdır:

Tekdüze nesnelerden oluşan bir diziniz varsa — hepsi aynı yapıyı paylaşan kullanıcılar, siparişler veya günlük girişleri listesi.
Bir aykırı değer arıyorsanız — sayı beklediğiniz yerde bir null, bir enum değerindeki yazım hatası, sadece bir satırda eksik bir alan. Tablolar, aykırı değerleri görsel olarak belirgin hale getirir çünkü gözünüz bir sütunu yukarıdan aşağıya tarayabilir; ağaç yapısı ise aynı anormalliği düzinelerce ayrı ayrı genişletilmiş düğümün içine gömer.
Elektronik tablo zihinsel modeline daha yakın bir şey istiyorsanız — sıralama yapmak veya hangi satırların aynı değeri paylaştığını gözle kontrol etmek gibi.

Yanlış seçim yapmanın somut hata durumu

Derinlemesine iç içe geçmiş bir API yanıtını (oturum nesnesinin içindeki kullanıcı nesnesinin içindeki kimlik doğrulama belirteçleri) tablo görünümünde açtığınızda, hücrelerin çoğunda sadece [Object] veya [Array] yazan bir tablo ile karşılaşırsınız — düzleştirme işlemi, iç içe geçmiş yapıyı yerleştirecek bir yer bulamaz, bu yüzden de işe yaramaz yer tutuculara dönüşür ve bunları yine de tıklamanız gerekir; bu da ağaç görünümünde başlamaktan kesinlikle daha kötüdür.

Neredeyse aynı olan 200 satırlık bir günlük girdisi dizisini ağaç görünümünde açtığınızda, status değerinin beklenmedik bir şekilde null olduğu tek satırı bulmak için tek tek genişletmeniz gereken 200 ayrı daraltılabilir düğümle karşılaşırsınız — tablo görünümünde iki saniye sürecek bir tarama, ağaç görünümünde dakikalarca tıklama gerektirir.

Basit bir kural

Önce şu soruyu sorun: İlginç farklılık kardeş öğeler arasında mı, yoksa derinlik boyunca mı?

Birbirine benzer birçok öğeyi karşılaştırıyorsanız (kardeş öğeler arasında) — tablo görünümünü kullanın.
Bir değeri iç içe geçmiş yapı boyunca takip ediyorsanız (derinlik boyunca) — ağaç görünümünü kullanın.

Verilerin okunabilir ve sözdizimsel olarak geçerli olmasına ihtiyaç duyduğunuz günlük JSON hata ayıklama işlemlerinde — girintileri kontrol etmek, köşeli parantezlerin eşleştiğini doğrulamak, sondaki virgülü tespit etmek gibi — her iki görünüm de kesinlikle gerekli değildir. Ham JSON’un düzgün girintili, okunabilir şekilde biçimlendirilmiş bir versiyonu (bir JSON biçimlendiricisi’nin size sunduğu gibi), çoğu hızlı kontrol için yapıyı zaten yeterince net bir şekilde ortaya koyar ve bir görüntüleyiciyi belirli bir moda geçirmekten daha hızlıdır. Veriler, baştan sona okunamayacak kadar büyük veya iç içe geçmişse, özellikle ağaç veya tablo görünümünü tercih edin.