Visualizzazione ad albero JSON vs. visualizzazione a tabella: quale delle due ti aiuta davvero a eseguire il debug più velocemente

La maggior parte dei visualizzatori JSON offre la possibilità di scegliere tra una visualizzazione ad albero (annidata, comprimibile, un valore per riga) e una visualizzazione a tabella (righe e colonne, in stile foglio di calcolo). Sembrano due diverse presentazioni degli stessi dati, quindi si è tentati di scegliere semplicemente quella che lo strumento apre per impostazione predefinita. Ma è un approccio sbagliato: le due visualizzazioni sono infatti ottimizzate per tipi di dati diversi e per attività di debug diverse, e scegliere quella sbagliata per il lavoro da svolgere comporta una perdita di tempo.

In cosa eccelle effettivamente ciascuna visualizzazione

La visualizzazione ad albero rispecchia la struttura reale del JSON: ogni oggetto e ogni array è un nodo comprimibile, ogni valore foglia si trova su una riga a sé stante accanto alla propria chiave. Questa è la scelta giusta quando:

Stai eseguendo il debug della struttura stessa: stai cercando di individuare dove si trova un valore all’interno di un oggetto profondamente annidato, oppure di confermare l’effettiva esistenza di un campo.
I dati sono irregolari: oggetti diversi nella stessa risposta presentano insiemi diversi di chiavi, campi opzionali o profondità di annidamento variabile. Una tabella non è in grado di rappresentare tutto ciò in modo chiaro; un albero sì.
È necessario visualizzare esplicitamente le relazioni padre-figlio, ad esempio per tracciare a quale array appartiene un determinato oggetto.

La vista tabella appiattisce un array di oggetti in righe e colonne, una colonna per ogni chiave. Questa opzione è preferibile quando:

Si dispone di un array di oggetti uniformi — un elenco di utenti, ordini o voci di log che condividono tutti la stessa struttura.
Si sta cercando un valore anomalo — un valore nullo dove ci si aspettava un numero, un errore di battitura in un valore di enumerazione, un campo mancante in una sola riga. Le tabelle rendono i valori anomali visivamente evidenti perché l’occhio può scansionare una colonna dall’alto verso il basso; un albero nasconde la stessa anomalia all’interno di dozzine di nodi espansi separatamente.
Si desidera qualcosa di più simile al modello mentale di un foglio di calcolo — ordinare o individuare a occhio quali righe condividono un valore.

La modalità di errore concreta di una scelta sbagliata

Apri una risposta API profondamente annidata (token di autenticazione all’interno di un oggetto utente all’interno di un oggetto sessione) nella vista tabella e otterrai una tabella in cui la maggior parte delle celle riporta semplicemente [Object] o [Array]: l’appiattimento non ha dove collocare la struttura annidata, quindi si riduce a segnaposto inutili su cui poi devi comunque cliccare, il che è decisamente peggio che partire dalla vista ad albero.

Apri un array di 200 righe di voci di log quasi identiche nella vista ad albero, e otterrete 200 nodi comprimibili separatamente che dovrete espandere uno alla volta per individuare l’unica riga in cui status è inaspettatamente null — una ricerca che richiederebbe due secondi in una tabella richiede minuti di clic in un albero.

Una semplice regola empirica

Ponetevi prima una domanda: la variazione di interesse si trova tra elementi dello stesso livello o in profondità?

Se state confrontando tra loro molti elementi simili (tra elementi dello stesso livello) — utilizzate la vista tabella.
Se stai seguendo un valore lungo una struttura annidata (in profondità), usa la visualizzazione ad albero.

Per il debug quotidiano dei file JSON, in cui hai principalmente bisogno che i dati siano leggibili e sintatticamente validi — controllare l’indentazione, verificare la corrispondenza delle parentesi, individuare una virgola finale — nessuna delle due visualizzazioni è strettamente necessaria. Una versione del JSON grezzo correttamente indentata e formattata (come quella fornita da un formattatore JSON) mostra già la struttura in modo sufficientemente chiaro per la maggior parte dei controlli rapidi, ed è più veloce da ottenere rispetto al passaggio di un visualizzatore a una modalità specifica. Ricorrete alla visualizzazione ad albero o a tabella in particolare quando i dati sono troppo voluminosi o troppo annidati per essere letti semplicemente dall’alto verso il basso.