Представление в виде JSON-дерева или в виде таблицы: что на самом деле помогает быстрее устранять ошибки

Большинство программ просмотра JSON предлагают на выбор два варианта отображения: древовидный (вложенный, со сворачиваемыми узлами, по одному значению в строке) и табличный (строки и столбцы, в стиле электронной таблицы). Они выглядят как два варианта представления одних и тех же данных, поэтому возникает соблазн просто выбрать тот, который инструмент открывает по умолчанию. Это ошибочный подход — на самом деле оба вида просмотра оптимизированы для разных типов данных и разных задач отладки, и выбор неподходящего для конкретной задачи будет стоить вам реального времени.

В чём на самом деле силен каждый вид

Деревовидный вид отражает реальную структуру JSON: каждый объект и массив представляет собой сворачиваемый узел, каждое конечное значение расположено в отдельной строке рядом со своим ключом. Это правильный выбор, когда:

Вы отлаживаете саму структуру — пытаетесь найти, где в глубоко вложенном объекте находится значение, или убедиться, что поле вообще существует.
Данные имеют нерегулярную структуру — разные объекты в одном и том же ответе имеют разные наборы ключей, необязательные поля или разную глубину вложенности. Таблица не может отобразить это наглядно; дерево — может.
Вам нужно явно видеть отношения «родитель-потомок», например, отслеживать, к какому массиву принадлежит конкретный объект.

Табличный вид преобразует массив объектов в строки и столбцы, по одному столбцу на каждый ключ. Это удобно, когда:

У вас есть массив однородных объектов — список пользователей, заказов или записей журнала, которые имеют одинаковую структуру.
Вы ищете аномалии — значение null там, где ожидалось число, опечатку в значении перечисления, отсутствующее поле в одной-единственной строке. В таблицах аномалии сразу бросаются в глаза, поскольку взгляд может пробегаться по столбцу сверху вниз; в дереве же такая же аномалия скрывается среди десятков отдельно развернутых узлов.
Вам нужна модель, ближе к представлению о таблице в электронном документе — сортировка или визуальная оценка, какие строки имеют одинаковое значение.

Конкретный случай ошибки при выборе

Откройте глубоко вложенный ответ API (токены аутентификации внутри объекта пользователя внутри объекта сессии) в табличном представлении, и вы получите таблицу, в которой в большинстве ячеек просто написано [Object] или [Array] — при сглаживании вложенной структуры некуда поместить, поэтому она сводится к бесполезным заполнителям, по которым вам всё равно придётся кликать, что значительно хуже, чем начинать с деревовидного представления.

Откройте массив из 200 строк почти идентичных записей журнала в деревовидном представлении, и вы получите 200 отдельно сворачиваемых узлов, которые придётся разворачивать по одному, чтобы найти ту единственную строку, где status неожиданно превратилось в null — просмотр, который в табличном представлении занял бы две секунды, в древовидном представлении отнимет несколько минут кликов.

Простое практическое правило

Сначала задайте себе один вопрос: интересующие вас различия находятся между одноуровневыми элементами или на разных уровнях глубины?

Если вы сравниваете между собой множество похожих элементов (на одном уровне) — используйте табличный вид.
Если вы отслеживаете значение вниз по вложенной структуре (по глубине) — используйте древовидный вид.

Для повседневной отладки JSON, когда вам в основном нужно, чтобы данные были читаемыми и синтаксически корректными — проверка отступов, подтверждение соответствия скобок, обнаружение лишней запятой — ни один из видов просмотра не является строго необходимым. Правильно отформатированная версия исходного JSON с отступом (такая, какую выдает форматировщик JSON) уже достаточно чётко отображает структуру для большинства быстрых проверок, и получить её быстрее, чем переключать просмотрщик в определённый режим. Используйте древовидный или табличный вид именно в тех случаях, когда данные слишком объёмны или слишком вложены, чтобы просто читать их сверху вниз.