JSON-trädvy vs. tabellvy: vilken hjälper dig faktiskt felsöka snabbare

De flesta JSON-visare ger dig ett val mellan en trädvy (nästlad, hopfällbar, ett värde per rad) och en tabellvy (rader och kolumner, kalkylbladsstil). De ser ut som två skal på samma data, så det är lockande att bara välja det ett verktyg öppnar som standard. Det är fel instinkt — de två vyerna är faktiskt optimerade för olika slags data och olika felsökningsuppgifter, och att välja fel för jobbet kostar dig riktig tid.

Vad varje vy faktiskt är bra på

Trädvy speglar JSON:ens verkliga struktur: varje objekt och array är en hopfällbar nod, varje löv-värde sitter på sin egen rad bredvid sin nyckel. Detta är rätt val när:

• Strukturen i sig är det du felsöker — du försöker hitta var i ett djupt nästlat objekt ett värde finns, eller bekräfta att ett fält överhuvudtaget existerar.
• Datan är oregelbunden — olika objekt i samma svar har olika uppsättningar nycklar, valfria fält eller varierande nästlingsdjup. En tabell kan inte representera det snyggt; ett träd kan.
• Du behöver se förälder-barn-relationer explicit, som att spåra vilken array ett visst objekt tillhör.

Tabellvy plattar ut en array av objekt till rader och kolumner, en kolumn per nyckel. Det vinner när:

• Du har en array av enhetliga objekt — en lista med användare, ordrar eller loggposter som alla delar samma form.
• Du letar efter en avvikelse — ett null där du förväntade dig ett tal, ett stavfel i ett enum-värde, ett saknat fält i bara en rad. Tabeller gör avvikelser visuellt uppenbara eftersom ögat kan skanna en kolumn uppifrån och ner; ett träd begraver samma anomali inuti dussintals separat expanderade noder.
• Du vill ha något närmare en kalkylbladsmodell — sortering, eller att snabbt se vilka rader som delar ett värde.

Det konkreta felläget av att välja fel

Öppna ett djupt nästlat API-svar (auth-tokens inuti ett användarobjekt inuti ett sessionsobjekt) i tabellvy, och du får en tabell där de flesta celler bara säger [Object] eller [Array] — utplattningen har ingenstans att lägga den nästlade strukturen, så den kollapsar till oanvändbara platshållare du ändå måste klicka in i, vilket är strikt sämre än att börja i trädvy.

Öppna en array med 200 nästan identiska loggposter i trädvy, och du får 200 separat hopfällbara noder du måste expandera en i taget för att hitta den enda raden där status oväntat är null — en skanning som skulle ta två sekunder i en tabell tar minuter av klickande i ett träd.

En enkel tumregel

Ställ en fråga först: är den intressanta variationen mellan syskon, eller mellan djup?

• Om du jämför många liknande poster med varandra (mellan syskon) — använd tabellvy.
• Om du följer ett värde ner genom nästlad struktur (mellan djup) — använd trädvy.

För vardaglig JSON-felsökning där du huvudsakligen bara behöver datan läsbar och syntaktiskt giltig — kontrollera indrag, bekräfta att parenteser matchar, hitta ett kvarglömt kommatecken — är ingen av vyerna strikt nödvändig. En korrekt indragen, snyggt formaterad version av den råa JSON:en (vad en JSON formatter ger dig) exponerar redan strukturen tillräckligt tydligt för de flesta snabba kontroller, och det går snabbare att komma till än att växla en visare till ett specifikt läge. Ta till träd- eller tabellvy specifikt när datan är för stor eller för nästlad för att bara läsas uppifrån och ner.