Деревоподібний вигляд JSON проти табличного: що насправді допомагає швидше налагоджувати

Більшість переглядачів JSON пропонують вибір між деревоподібним виглядом (вкладений, згортається, одне значення на рядок) і табличним виглядом (рядки та стовпці, як у таблиці). Вони виглядають як дві шкіри на одних і тих самих даних, тож виникає спокуса просто обрати той режим, який інструмент відкриває за замовчуванням. Це хибний інстинкт — насправді обидва режими оптимізовані під різні форми даних і різні задачі налагодження, і вибір неправильного варіанта коштує реального часу.

У чому насправді сильний кожен режим

Деревоподібний вигляд відображає реальну структуру JSON: кожен об’єкт і масив — це вузол, який можна згорнути, а кожне кінцеве значення розташоване на власному рядку поруч зі своїм ключем. Це правильний вибір, коли:

Ви налагоджуєте саму структуру — намагаєтеся знайти, де саме в глибоко вкладеному об’єкті міститься значення, або перевіряєте, чи взагалі існує певне поле.
Дані нерегулярні — різні об’єкти в одній і тій самій відповіді мають різні набори ключів, необов’язкові поля або різну глибину вкладеності. Таблиця не може чітко це відобразити, а дерево — може.
Вам потрібно явно бачити зв’язки між батьківськими та дочірніми елементами, наприклад, простежити, якому масиву належить конкретний об’єкт.

Табличний вигляд розгортає масив об’єктів у рядки та стовпці, по одному стовпцю на кожен ключ. Це виграшний варіант, коли:

У вас є масив однорідних об’єктів — список користувачів, замовлень чи записів журналу, які мають однакову форму.
Ви шукаєте аномалію — null там, де очікували число, помилку в значенні enum, поле, відсутнє лише в одному рядку. Таблиці роблять аномалії візуально очевидними, бо погляд може пробігти стовпець зверху вниз; дерево ж ховає ту саму аномалію всередині десятків окремо розгорнутих вузлів.
Вам потрібна модель мислення, ближча до електронної таблиці — сортування або швидка оцінка того, які рядки мають спільне значення.

Конкретний сценарій провалу при неправильному виборі

Відкрийте глибоко вкладену відповідь API (токени автентифікації всередині об’єкта користувача, який всередині об’єкта сесії) у табличному вигляді — і ви отримаєте таблицю, де більшість комірок просто містять [Object] або [Array]: розгортанню нема куди подіти вкладену структуру, тож вона згортається в марні заглушки, у які потім однаково доведеться клікати, а це строго гірше, ніж одразу почати з деревоподібного вигляду.

Відкрийте масив із 200 майже ідентичних записів журналу в деревоподібному вигляді — і ви отримаєте 200 окремо згорнутих вузлів, які доведеться розгортати по одному, щоб знайти той єдиний рядок, де status несподівано має значення null. Перевірка, яка в таблиці зайняла б дві секунди, у дереві перетворюється на хвилини клікання.

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

Спершу задайте собі одне питання: цікава відмінність проявляється між сусідніми елементами чи по глибині?

Якщо ви порівнюєте багато схожих елементів між собою (по сусідніх елементах) — використовуйте табличний вигляд.
Якщо ви простежуєте значення вглиб через вкладену структуру (по глибині) — використовуйте деревоподібний вигляд.

Для повсякденного налагодження JSON, коли вам переважно потрібно, щоб дані були читабельними та синтаксично коректними — перевірити відступи, підтвердити, що дужки збігаються, знайти зайву кому в кінці — жоден із цих режимів насправді не є обов’язковим. Правильно відформатований, “красиво надрукований” варіант вихідного JSON (те, що дає форматувальник JSON) вже досить чітко розкриває структуру для більшості швидких перевірок, і дістатися до нього швидше, ніж перемикати переглядач у конкретний режим. Звертайтеся до деревоподібного або табличного вигляду саме тоді, коли дані заскладні або занадто вкладені, щоб просто читати їх зверху вниз.