JSON 뷰어

낯선 응답 읽기

트리가 정렬된 텍스트보다 나은 이유는 구조를 보여 준다는 점입니다. 들여쓴 텍스트는 문서에 무엇이 들어 있는지 알려 주고, 트리는 그것이 어떻게 조직되어 있는지 알려 줍니다. 내가 만들지 않은 API의 응답을 받았을 때 실제로 궁금한 것은 후자입니다.

처음 보는 문서를 다룰 때 쓸 만한 순서는 이렇습니다.

1. 붙여넣습니다. 루트가 자동으로 열리고 작은 자식 객체도 함께 열려, 최상위 구조가 클릭 없이 드러납니다.
2. 상태 표시줄을 읽습니다. 깊이는 중첩이 얼마나 내려가는지 알려 주고, 키는 전체와 고유 개수를 함께 보여 줍니다. 둘의 차이가 크다면 넓은 설정 객체가 아니라 반복되는 레코드를 보고 있다는 뜻입니다.
3. 루트가 객체 배열이라면 표로 바꾸세요. 레코드는 형제 서브트리로 비교하는 것보다 행으로 비교하는 편이 훨씬 쉽습니다.
4. 필요한 필드를 검색한 다음, 그 행에서 경로 복사를 눌러 코드에 쓸 접근 식을 얻습니다.

각 행이 알려 주는 것

• 접힌 컨테이너에는 개수가 붙습니다. 3개 항목 또는 5개 키처럼 표시되어, 펼치기 전에 그 가지를 열어 볼 만한지 판단할 수 있습니다.
• 값은 타입별로 색이 다르고 문자열은 따옴표를 유지합니다. "42"로 표시된 숫자는 문자열이며, 대개 찾고 있던 버그가 바로 이 차이입니다.
• null은 빈 칸이 아니라 명시적으로 표시됩니다. null인 것과 키가 없는 것은 다른 이야기이기 때문입니다.
• 모든 행에 값 복사와 경로 복사 버튼이 있습니다. 값 복사는 문자열이면 원문 텍스트를, 컨테이너면 정렬된 JSON을 줍니다.

큰 문서가 계속 반응하는 이유

뷰어는 DOM을 필요할 때만 만듭니다. 접힌 노드는 자식 요소를 아예 갖지 않고, 펼치면 바로 아래 자식만 만들어집니다. 큰 배열은 한 번에 200개씩입니다. 따라서 20MB 문서의 비용은 파싱 한 번과 첫 화면의 몇 줄뿐이며, 브라우저가 응답하기 전에 배치해야 할 수백만 노드가 아닙니다.

펼치기는 정말로 비용이 큰 유일한 동작이라 노드 20,000개에서 멈추고 그 사실을 알려 줍니다. 문서 전체를 읽으려면 정렬된 텍스트 보기가 더 적합합니다.

문자열 안에 담겨 온 JSON 읽기

로그 파이프라인과 메시지 큐는 JSON을 JSON 문자열로 인코딩해 전달하는 일이 흔합니다. "{\"id\":7,\"ok\":true}" 같은 모습으로 도착합니다. 붙여넣고 이스케이프 해제를 누르면 겉의 문자열이 파싱되고 안쪽 문서가 해독되어 트리가 실제 구조를 그립니다. 두 번 이상 인코딩된 데이터라면 그만큼 반복하면 됩니다.