Vizualizare JSON arbore vs. tabel: care te ajută de fapt să depanezi mai rapid

Majoritatea vizualizatoarelor JSON îți dau de ales între o vizualizare de tip arbore (imbricată, pliabilă, o valoare pe rând) și una de tip tabel (rânduri și coloane, ca într-un spreadsheet). Arată ca două „skinuri“ pe aceleași date, așa că e tentant să o alegi pur și simplu pe cea deschisă implicit. E instinctul greșit — cele două vizualizări sunt de fapt optimizate pentru forme diferite de date și pentru sarcini de depanare diferite, iar alegerea greșită te costă timp real.

La ce e bună de fapt fiecare vizualizare

Vizualizarea arbore oglindește structura reală a JSON-ului: fiecare obiect și fiecare array e un nod pliabil, fiecare valoare-frunză stă pe propriul rând, lângă cheia ei. E alegerea potrivită când:

• Structura în sine e ceea ce depanezi — încerci să afli unde anume trăiește o valoare într-un obiect adânc imbricat sau să confirmi că un câmp există de fapt.
• Datele sunt neregulate — obiecte diferite din același răspuns au seturi diferite de chei, câmpuri opționale sau adâncimi de imbricare variabile. Un tabel nu poate reprezenta asta curat; un arbore da.
• Ai nevoie să vezi explicit relațiile părinte-copil, de exemplu ca să afli cărui array îi aparține un anumit obiect.

Vizualizarea tabel aplatizează un array de obiecte în rânduri și coloane, câte o coloană per cheie. Câștigă atunci când:

• Ai un array de obiecte uniforme — o listă de utilizatori, comenzi sau intrări de log care au toate aceeași formă.
• Cauți o anomalie — un null unde așteptai un număr, o greșeală de scriere într-o valoare de enum, un câmp lipsă doar într-un rând. Tabelele fac anomaliile vizibile instant, pentru că ochiul poate scana o coloană de sus până jos; un arbore îngroapă aceeași anomalie în zeci de noduri care trebuie extinse separat.
• Vrei ceva mai apropiat de modelul mental al unui spreadsheet — sortare sau observarea rândurilor care împart aceeași valoare.

Modul concret de eșec al alegerii greșite

Deschide un răspuns API adânc imbricat (tokenuri de autentificare într-un obiect user, într-un obiect session) în vizualizarea tabel, și obții un tabel în care majoritatea celulelor spun doar [Object] sau [Array] — aplatizarea nu are unde să pună structura imbricată, așa că totul se prăbușește în substituenți inutili în care oricum trebuie să dai clic, ceea ce e strict mai rău decât să fi început în arbore.

Deschide un array de 200 de rânduri de intrări de log aproape identice în vizualizarea arbore, și primești 200 de noduri pliabile pe care trebuie să le extinzi unul câte unul ca să găsești singurul rând în care status e, pe neașteptate, null — o scanare care ar dura două secunde într-un tabel devine minute de clicuri într-un arbore.

O regulă simplă

Pune-ți mai întâi o singură întrebare: variația interesantă e între elemente-frate sau pe adâncime?

• Dacă compari multe elemente similare între ele (între frați) — folosește tabelul.
• Dacă urmărești o valoare în jos, prin structura imbricată (pe adâncime) — folosește arborele.

Pentru depanarea JSON de zi cu zi, unde ai nevoie în principal ca datele să fie lizibile și valide sintactic — verificarea indentării, confirmarea parantezelor, depistarea unei virgule finale — niciuna dintre vizualizări nu e strict necesară. O versiune corect indentată, formatată frumos, a JSON-ului brut (ce îți dă un JSON formatter) expune deja structura suficient de clar pentru majoritatea verificărilor rapide și e mai rapid de obținut decât comutarea unui vizualizator într-un anumit mod. Apelează la arbore sau tabel mai ales când datele sunt prea mari sau prea imbricate ca să le citești pur și simplu de sus până jos.