Xem JSON dạng cây hay dạng bảng: cái nào thực sự giúp bạn debug nhanh hơn

Hầu hết các công cụ xem JSON đều cho bạn lựa chọn giữa chế độ xem dạng cây (lồng nhau, có thể thu gọn, mỗi giá trị một dòng) và chế độ xem dạng bảng (hàng và cột, giống bảng tính). Chúng trông như hai lớp giao diện khác nhau cho cùng một dữ liệu, nên rất dễ chỉ chọn bất cứ chế độ nào công cụ mở mặc định. Đó là phản xạ sai — hai chế độ xem này thực ra được tối ưu cho những dạng dữ liệu và tác vụ debug khác nhau, và chọn sai chế độ cho công việc sẽ khiến bạn tốn thời gian thật sự.

Mỗi chế độ xem thực sự mạnh ở điểm nào

Chế độ xem dạng cây phản ánh đúng cấu trúc thực của JSON: mỗi object và array là một nút có thể thu gọn, mỗi giá trị lá nằm trên dòng riêng cạnh khóa của nó. Đây là lựa chọn đúng khi:

Chính cấu trúc là thứ bạn đang debug — bạn đang cố tìm vị trí của một giá trị nằm sâu trong object lồng nhau, hoặc xác nhận một trường có tồn tại hay không.
Dữ liệu không đồng nhất — các object khác nhau trong cùng một phản hồi có bộ khóa khác nhau, trường tùy chọn, hoặc độ sâu lồng nhau khác nhau. Bảng không thể biểu diễn điều đó một cách gọn gàng; cây thì có thể.
Bạn cần thấy rõ ràng mối quan hệ cha-con, chẳng hạn như truy ra một object cụ thể thuộc về array nào.

Chế độ xem dạng bảng làm phẳng một mảng các object thành hàng và cột, mỗi khóa một cột. Chế độ này thắng thế khi:

Bạn có một mảng gồm các object đồng nhất — danh sách người dùng, đơn hàng, hoặc bản ghi log đều có cùng cấu trúc.
Bạn đang quét tìm một điểm bất thường — một giá trị null ở nơi lẽ ra phải là số, một lỗi chính tả trong giá trị enum, một trường bị thiếu chỉ ở một hàng. Bảng làm cho những điểm bất thường trở nên dễ nhận thấy về mặt thị giác vì mắt bạn có thể quét một cột từ trên xuống dưới; cây lại chôn vùi cùng một bất thường đó trong hàng chục nút phải mở riêng lẻ.
Bạn muốn một tư duy gần giống bảng tính hơn — sắp xếp, hoặc nhìn lướt qua để biết hàng nào có chung một giá trị.

Hậu quả cụ thể khi chọn sai

Mở một phản hồi API lồng sâu (token xác thực nằm trong object người dùng, nằm trong object phiên đăng nhập) bằng chế độ xem bảng, bạn sẽ được một bảng mà phần lớn ô chỉ ghi [Object] hoặc [Array] — việc làm phẳng không có chỗ để đặt cấu trúc lồng nhau, nên nó thu gọn thành những ô giữ chỗ vô dụng mà sau đó bạn vẫn phải nhấp vào — điều này rõ ràng tệ hơn so với việc bắt đầu ngay bằng chế độ xem cây.

Mở một mảng 200 dòng gồm các bản ghi log gần như giống hệt nhau bằng chế độ xem cây, bạn sẽ có 200 nút có thể thu gọn riêng lẻ mà bạn phải mở từng cái một để tìm ra dòng duy nhất có status bất ngờ là null — một thao tác quét chỉ mất hai giây trong bảng lại mất nhiều phút nhấp chuột trong cây.

Một quy tắc đơn giản để ghi nhớ

Hãy tự hỏi một câu trước tiên: sự khác biệt đáng chú ý nằm giữa các phần tử cùng cấp, hay giữa các tầng sâu?

Nếu bạn đang so sánh nhiều mục tương tự nhau (giữa các phần tử cùng cấp) — dùng chế độ xem bảng.
Nếu bạn đang lần theo một giá trị xuyên qua cấu trúc lồng nhau (theo chiều sâu) — dùng chế độ xem cây.

Với việc debug JSON thường ngày, khi bạn chủ yếu chỉ cần dữ liệu dễ đọc và đúng cú pháp — kiểm tra thụt lề, xác nhận dấu ngoặc khớp nhau, phát hiện dấu phẩy thừa — thì không chế độ xem nào thực sự cần thiết. Một phiên bản JSON thô được thụt lề đúng chuẩn, in đẹp (chính là những gì một công cụ định dạng JSON mang lại) đã đủ để bộc lộ rõ cấu trúc cho hầu hết các lần kiểm tra nhanh, và việc lấy được nó cũng nhanh hơn so với việc chuyển công cụ xem sang một chế độ cụ thể. Chỉ dùng đến chế độ xem cây hoặc bảng khi dữ liệu quá lớn hoặc quá lồng ghép để đọc trực tiếp từ trên xuống dưới.