Visualização em árvore JSON vs. visualização em tabela: qual delas ajuda realmente a depurar mais rapidamente

A maioria dos visualizadores de JSON permite escolher entre uma visualização em árvore (aninhada, recolhível, um valor por linha) e uma visualização em tabela (linhas e colunas, ao estilo de uma folha de cálculo). Parecem duas formas diferentes de apresentar os mesmos dados, pelo que é tentador escolher simplesmente aquela que a ferramenta abre por predefinição. Esse é o instinto errado — as duas visualizações estão, na verdade, otimizadas para diferentes formatos de dados e diferentes tarefas de depuração, e escolher a visualização errada para a tarefa em questão custa-lhe tempo real.

Em que é que cada visualização se destaca

A visualização em árvore reflete a estrutura real do JSON: cada objeto e matriz é um nó recolhível, cada valor folha ocupa a sua própria linha ao lado da sua chave. Esta é a escolha certa quando:

• A própria estrutura é o que está a depurar — está a tentar descobrir onde se encontra um valor num objeto profundamente aninhado, ou confirmar se um campo existe de todo.
• Os dados são irregulares — objetos diferentes na mesma resposta têm conjuntos diferentes de chaves, campos opcionais ou profundidades de aninhamento variáveis. Uma tabela não consegue representar isso de forma clara; uma árvore consegue.
• Precisa de ver explicitamente as relações pai-filho, como rastrear a que matriz um determinado objeto pertence.

A visualização em tabela transforma uma matriz de objetos em linhas e colunas, uma coluna por chave. Esta opção é a mais adequada quando:

• Tem uma matriz de objetos uniformes — uma lista de utilizadores, encomendas ou entradas de registo que partilham todos a mesma estrutura.
• Está à procura de um valor atípico — um nulo onde esperavas um número, um erro ortográfico num valor de enumeração, um campo em falta numa única linha. As tabelas tornam os valores atípicos visualmente evidentes, porque o olho consegue percorrer uma coluna de cima para baixo; uma árvore oculta a mesma anomalia dentro de dezenas de nós expandidos separadamente.
• Pretende algo mais próximo do modelo mental de uma folha de cálculo — ordenar ou identificar rapidamente quais as linhas que partilham um valor.

O modo de falha concreto de escolher mal

Abra uma resposta de API profundamente aninhada (tokens de autenticação dentro de um objeto de utilizador dentro de um objeto de sessão) na vista de tabela e obterá uma tabela em que a maioria das células apresenta apenas [Object] ou [Array] — a simplificação não tem onde colocar a estrutura aninhada, por isso reduz-se a espaços reservados inúteis nos quais, de qualquer forma, terá de clicar, o que é claramente pior do que começar na vista em árvore.

Abra uma matriz de 200 linhas com entradas de registo quase idênticas na vista em árvore, e obtém 200 nós que podem ser recolhidos separadamente, que tem de expandir um de cada vez para identificar a única linha em que «status» é, inesperadamente, «null» — uma verificação que demoraria dois segundos numa tabela demora minutos de cliques numa árvore.

Uma regra prática simples

Faça primeiro uma pergunta: a variação interessante ocorre entre itens do mesmo nível ou ao longo da profundidade?

• Se estiver a comparar muitos itens semelhantes entre si (entre itens do mesmo nível) — utilize a vista em tabela.
• Se estiver a seguir um valor ao longo de uma estrutura aninhada (ao longo da profundidade) — utilize a vista em árvore.

Para a depuração diária de JSON, em que precisa principalmente que os dados sejam legíveis e sintaticamente válidos — verificar a indentação, confirmar se os parênteses correspondem, detetar uma vírgula final — nenhuma das vistas é estritamente necessária. Uma versão do JSON bruto devidamente indentada e com formatação elegante (aquela que um formatador de JSON lhe fornece) já expõe a estrutura de forma suficientemente clara para a maioria das verificações rápidas, e é mais rápido aceder a ela do que mudar um visualizador para um modo específico. Opte pela visualização em árvore ou em tabela especificamente quando os dados forem demasiado grandes ou demasiado aninhados para serem lidos simplesmente de cima para baixo.