JSON tree view vs. table view: hvilken hjælper dig faktisk med at fejlsøge hurtigere

De fleste JSON-viewere giver dig valget mellem en tree view (indlejret, sammenklappelig, én værdi pr. linje) og en table view (rækker og kolonner, som et regneark). De ligner to skind på den samme data, så det er fristende bare at vælge den, et værktøj åbner som standard. Det er den forkerte tilgang — de to visninger er faktisk optimeret til forskellige typer data og forskellige fejlsøgningsopgaver, og at vælge den forkerte til opgaven koster dig reel tid.

Hvad hver visning faktisk er god til

Tree view afspejler JSON’ens virkelige struktur: hvert objekt og array er en sammenklappelig node, hver blad-værdi står på sin egen linje ved siden af sin nøgle. Det er det rigtige valg, når:

• Selve strukturen er det, du fejlsøger — du prøver at finde hvor i et dybt indlejret objekt en værdi ligger, eller bekræfte at et felt overhovedet findes.
• Dataen er uregelmæssig — forskellige objekter i samme svar har forskellige sæt af nøgler, valgfri felter eller varierende indlejringsdybde. Det kan en tabel ikke gengive pænt; det kan et træ.
• Du skal se forælder-barn-relationer eksplicit, som at spore hvilket array et bestemt objekt hører til.

Table view flader et array af objekter ud til rækker og kolonner, én kolonne pr. nøgle. Det vinder når:

• Du har et array af ensartede objekter — en liste af brugere, ordrer eller logposter, der alle deler samme form.
• Du scanner efter en afviger — en null hvor du forventede et tal, en tastefejl i en enum-værdi, et manglende felt i kun én række. Tabeller gør afvigere visuelt oplagte, fordi dit øje kan scanne en kolonne top til bund; et træ begraver den samme anomali inde i snesevis af separat udfoldede noder.
• Du vil have noget tættere på en regnearks-tankegang — sortering, eller at aflæse hvilke rækker der deler en værdi.

Den konkrete fejltype ved at vælge forkert

Åbn et dybt indlejret API-svar (auth-tokens inde i et brugerobjekt inde i et sessionsobjekt) i table view, og du får en tabel, hvor de fleste celler bare siger [Object] eller [Array] — udfladningen har ingen steder at putte den indlejrede struktur, så den kollapser til ubrugelige pladsholdere, du alligevel bagefter skal klikke dig ind i, hvilket er strengt værre end at starte i tree view.

Åbn et array med 200 næsten identiske logposter i tree view, og du får 200 separat sammenklappelige noder, du skal udfolde én ad gangen for at finde den ene række, hvor status uventet er null — en scanning, der ville tage to sekunder i en tabel, tager minutter med klik i et træ.

En simpel tommelfingerregel

Stil ét spørgsmål først: er den interessante variation på tværs af søskende eller på tværs af dybde?

• Hvis du sammenligner mange lignende elementer med hinanden (på tværs af søskende) — brug table view.
• Hvis du følger en værdi ned gennem indlejret struktur (på tværs af dybde) — brug tree view.

Til hverdagslig JSON-fejlsøgning, hvor du mest bare skal have dataen læselig og syntaktisk gyldig — tjekke indrykning, bekræfte at parenteser passer sammen, finde et overskydende komma — er ingen af visningerne strengt nødvendig. En korrekt indrykket, pænt formateret version af den rå JSON (det en JSON formatter giver dig) afslører allerede strukturen tydeligt nok til de fleste hurtige tjek, og det er hurtigere at nå frem til end at skifte en viewer til en bestemt tilstand. Grib fat i tree eller table view specifikt, når dataen er for stor eller for indlejret til bare at læse fra top til bund.