JSON fanézet vagy táblázatnézet: melyikkel debugolsz ténylegesen gyorsabban

A legtöbb JSON-megjelenítő választási lehetőséget ad a fanézet (beágyazott, összecsukható, soronként egy érték) és a táblázatnézet (sorok és oszlopok, táblázatkezelő-stílusban) között. Két külsőnek tűnnek ugyanazon az adaton, így csábító egyszerűen azt választani, amelyiket az eszköz alapból megnyitja. Ez rossz ösztön — a két nézet valójában eltérő adatformákra és eltérő hibakeresési feladatokra van optimalizálva, és ha rosszul választasz a feladathoz, az valódi idődbe kerül.

Miben jó valójában az egyik és a másik

A fanézet a JSON valós szerkezetét tükrözi: minden objektum és tömb összecsukható csomópont, minden levélérték a saját sorában ül a kulcsa mellett. Ez a jó választás, amikor:

• Maga a szerkezet az, amit debugolsz — azt próbálod megtalálni, egy mélyen beágyazott objektumban hol él egy érték, vagy egyáltalán ellenőriznéd, hogy egy mező létezik-e.
• Az adat szabálytalan — ugyanabban a válaszban a különböző objektumoknak eltérő kulcskészletük, opcionális mezőik vagy változó beágyazási mélységük van. Egy táblázat ezt nem tudja tisztán megjeleníteni; egy fa igen.
• Explicit módon kell látnod a szülő-gyerek kapcsolatokat, például visszakövetni, melyik tömbhöz tartozik egy adott objektum.

A táblázatnézet objektumok tömbjét lapítja sorokká és oszlopokká, kulcsonként egy oszloppal. Ez akkor nyer, amikor:

• Egyforma objektumok tömbjéd van — felhasználók, rendelések vagy naplóbejegyzések listája, amelyek mind ugyanolyan alakúak.
• Kilógó értéket keresel — egy null ott, ahol számot vártál, egy elgépelés egy enum-értékben, egy hiányzó mező egyetlen sorban. A táblázatok vizuálisan nyilvánvalóvá teszik a kiugró értékeket, mert a szemed fentről lefelé végig tud pásztázni egy oszlopot; a fa ugyanazt az anomáliát tucatnyi külön-külön kibontandó csomópontba temeti.
• Valami táblázatkezelőhöz közelebbi mentális modellt szeretnél — rendezést, vagy ránézésre megállapítani, mely sorok osztoznak egy értéken.

A rossz választás konkrét hibamódja

Nyiss meg egy mélyen beágyazott API-választ (auth tokenek egy user objektumban egy session objektumban) táblázatnézetben, és olyan táblázatot kapsz, ahol a legtöbb cellában csak annyi áll: [Object] vagy [Array] — a lapításnak nincs hová tennie a beágyazott szerkezetet, így haszontalan helykitöltőkké omlik össze, amelyekbe úgyis bele kell kattintanod — ez szigorúan rosszabb, mint eleve fanézetben kezdeni.

Nyiss meg egy 200 soros, majdnem azonos naplóbejegyzésekből álló tömböt fanézetben, és 200 külön összecsukható csomópontot kapsz, amelyeket egyenként kell kibontanod, hogy kiszúrd azt az egy sort, ahol a status váratlanul null — egy pásztázás, ami táblázatban két másodperc lenne, a fában percekig tartó kattintgatás.

Egyszerű hüvelykujjszabály

Először tedd fel az egyetlen kérdést: az érdekes eltérés a testvérelemek között van, vagy a mélység mentén?

• Ha sok hasonló elemet hasonlítasz egymáshoz (testvérek között) — használj táblázatnézetet.
• Ha egy értéket követsz lefelé a beágyazott szerkezeten át (mélység mentén) — használj fanézetet.

A hétköznapi JSON-hibakereséshez, ahol főleg olvashatóan és szintaktikailag érvényesen kell látnod az adatot — behúzás ellenőrzése, zárójelpárok megerősítése, záró vessző kiszúrása — egyik nézet sem feltétlenül szükséges. A nyers JSON megfelelően behúzott, szépen formázott változata (amit egy JSON-formázó ad) a legtöbb gyors ellenőrzéshez már elég tisztán mutatja a szerkezetet, és gyorsabban elérhető, mint egy megjelenítőt adott módba kapcsolni. Kifejezetten akkor nyúlj fa- vagy táblázatnézethez, ha az adat túl nagy vagy túl beágyazott ahhoz, hogy egyszerűen fentről lefelé végigolvasd.