JSONin puunäkymä vs. taulukkonäkymä: kumpi oikeasti nopeuttaa debuggaustasi

Useimmat JSON-katselimet antavat valita puunäkymän (sisäkkäinen, supistettava, yksi arvo per rivi) ja taulukkonäkymän (rivit ja sarakkeet, taulukkolaskentatyyliin) välillä. Ne näyttävät kahdelta eri kuorelta saman datan päällä, joten on houkuttelevaa valita vain se, jonka työkalu avaa oletuksena. Se on väärä vaisto — näkymät on oikeasti optimoitu erimuotoiselle datalle ja eri debuggaustehtäville, ja väärän valinta maksaa oikeaa aikaa.

Missä kumpikin näkymä on oikeasti hyvä

Puunäkymä heijastaa JSONin todellista rakennetta: jokainen objekti ja taulukko on supistettava solmu, jokainen lehtiarvo istuu omalla rivillään avaimensa vieressä. Tämä on oikea valinta, kun:

• Debuggaat itse rakennetta — yrität löytää, missä kohtaa syvästi sisäkkäistä objektia arvo asuu, tai varmistaa, että kenttä ylipäätään on olemassa.
• Data on epäsäännöllistä — saman vastauksen eri objekteilla on eri avainjoukot, valinnaisia kenttiä tai vaihteleva sisäkkäisyyssyvyys. Taulukko ei pysty esittämään sitä siististi; puu pystyy.
• Sinun täytyy nähdä vanhempi–lapsi-suhteet eksplisiittisesti, esimerkiksi jäljittää, mihin taulukkoon tietty objekti kuuluu.

Taulukkonäkymä litistää objektitaulukon riveiksi ja sarakkeiksi, yksi sarake per avain. Tämä voittaa, kun:

• Sinulla on taulukko yhdenmukaisia objekteja — lista käyttäjiä, tilauksia tai lokimerkintöjä, joilla kaikilla on sama muoto.
• Etsit poikkeamaa — null siellä missä odotit numeroa, kirjoitusvirhe enum-arvossa, puuttuva kenttä vain yhdellä rivillä. Taulukot tekevät poikkeamista visuaalisesti ilmeisiä, koska silmäsi voi skannata sarakkeen ylhäältä alas; puu hautaa saman poikkeaman kymmenien erikseen avattavien solmujen sisään.
• Haluat jotain lähempänä taulukkolaskennan ajattelumallia — lajittelua tai silmämääräistä vertailua siitä, mitkä rivit jakavat arvon.

Konkreettinen epäonnistumistapa väärässä valinnassa

Avaa syvästi sisäkkäinen API-vastaus (auth-tokenit käyttäjäobjektin sisällä sessio-objektin sisällä) taulukkonäkymässä, ja saat taulukon, jonka useimmissa soluissa lukee vain [Object] tai [Array] — litistyksellä ei ole paikkaa sisäkkäiselle rakenteelle, joten se romahtaa hyödyttömiksi paikanpitäjiksi, joita joudut joka tapauksessa klikkailemaan auki. Se on suoraan huonompi kuin aloittaa puunäkymästä.

Avaa 200 rivin taulukollinen lähes identtisiä lokimerkintöjä puunäkymässä, ja saat 200 erikseen supistettavaa solmua, jotka pitää avata yksi kerrallaan löytääksesi sen yhden rivin, jossa status on yllättäen null — skannaus, joka veisi kaksi sekuntia taulukossa, vie minuutteja klikkailua puussa.

Yksinkertainen nyrkkisääntö

Kysy ensin yksi kysymys: onko kiinnostava vaihtelu sisarusten välillä vai syvyyssuunnassa?

• Jos vertaat monia samankaltaisia kohteita toisiinsa (sisarusten välillä) — käytä taulukkonäkymää.
• Jos seuraat arvoa alas sisäkkäisen rakenteen läpi (syvyyssuunnassa) — käytä puunäkymää.

Arkiseen JSON-debuggaukseen, jossa data pitää lähinnä saada luettavaksi ja syntaktisesti kelvolliseksi — sisennysten tarkistus, sulkeiden täsmäys, ylimääräisen pilkun bongaus — kumpaakaan näkymää ei varsinaisesti tarvita. Oikein sisennetty, siististi tulostettu versio raakadatasta (jonka JSON-muotoilija antaa) paljastaa rakenteen jo riittävän selkeästi useimpiin pikatarkistuksiin, ja siihen pääsee nopeammin kuin katselimen vaihtamiseen tiettyyn tilaan. Tartu puu- tai taulukkonäkymään nimenomaan silloin, kun data on liian suurta tai liian sisäkkäistä luettavaksi ylhäältä alas.