React로 앱을 만들다보면 어느새 컴포넌트가 수십개가 된다. 앱 안의 페이지 안의 헤더 안의 푸터 속의 리스트 안의 아이템 안의..
그러다 문득 궁금해졌다. React가 대체 이 복잡한 구조를 어떻게 파악하고 관리하나?
핵심은 트리 구조에 있다.
사실 UI를 트리로 생각하는건 React만의 방식은 아니다. 웹 브라우저가 HTML 문서를 다루는 DOM과 CSSOM 구조도 트리이고, 모바일 플랫폼의 화면 구성 방식도 근본적으로는 다 트리라고 한다. (여기서 트리는 자료구조 공부할 때 뱌로 그 트리다! DOM은 이진 트리는 아님. 당연함 개수에 제한이 없다. <div> 하나에 <span>이 백개 들어갈 수도 있으니까)
React도 컴포넌트 간의 관계를 정리하고 모델링 하기 위해 트리 구조를 사용한다. 이때, 컴포의 주요 특징은 다른 컴포넌트의 컴포넌트를 구성한다는 것이다. 닉값하네
이렇게 중첩된 관계를 Render Tree라는 구조를 통해 모델링하고 렌더링한다.
한편, Render Tree는 컴포넌트 자체와 화면의 구조에만 집중하기 때문에, HTML 태그 같은건 포함되어 있지 않다. 이런 추상성 덕분에 React가 platform agnostic할 수 있다.
- Platform Agnostic : 플랫폼에 구애받지 않는다는 것, 즉 어디서든 잘 돌아간단 거다. react native처럼 ios, android 어디든 돌아간다구.
이쯤에서 공식 DOCS의 예시를 빌려오겠다.
여기 명언을 추천해주는 리액트 앱이 있다.
App.js 가 InspirationGenerator와 FancyText를 렌더하고 , InspirationGenerator는
inspiration.type 값이 quote인지 color인지에 따라 다른 자식(문구or색상)을 조건부로 렌더한다
그런데 이런 경우 렌더트리는 각 render pass마다 다르게 생겼을 것이다.
여기서 렌더 트리의 동적 변화성을 알 수 있다.
당장 로그인 기능만 봐도, 로그인 상태일 때는 유저 프로필이 트리에 매달려있겠지만, 로그아웃 후에는 버튼 컴포넌트가 그 자리에 있을 것이다.
즉, 앱의 상태가 변할 때마다 렌더 트리는 계속해서 만들어진다.
이러한 렌더링 트리 지식은 최상위 컴포넌트와 리프 컴포넌트를 구분할 수 있는 바탕이 된다.
그럼 이런 지식은 어디서 써먹을 수 있을까?
루트 컴포넌트에 가장 가까운 최상위 노드는 하위 노드의 렌더링 성능에 영향을 미치기 때문에, 개발 시 앱의 데이터 흐름과 성능 이해에 유용할 수 밖에 없다. 이걸 알았다면 그때 그렇게 props 폭포를 만들지 않았을텐데..
한편 이제 리액트가 만든 또 다른 트리가 하나 더 있다.
그것은 바로 모듈 의존성 트리
위의 렌더 트리와 비슷하게 생겼지만 약간 다르다. 잘 보면, 이녀석의 가지를 따라갔을 때 모듈이 서로 어떻게 import되었는지 경로가 보인다. 즉, 어떤 컴포넌트가 어떤 함수나 상수를 가져다 쓰고 있는지 보여주는 자바스크립트 모듈의 지도라고 할 수 있다.
렌더트리에는 없던, inspirations.js같은 비컴포넌트 모듈도 표시된다.
또한 Copyright.js는 App.js 아래에 나타나있는데, 렌더트리에서는 컴포넌트인 Copyright가 InspirationGenerator의 자식으로 나타났었다.
이는 두 트리의 계층 구조 기준이 다르기 때문이다. 만약 특정 컴포넌트를 App에서 import 했더라도 실제 렌더링은 다른 컴포넌트의 자식(props)으로 전달되어 화면에 그려질 수 있기 때문이다.
요약 : 의존성 트리는 '파일이 어디서 불러와졌는지'를, 렌더 트리는 '화면에 어떻게 배치되는지'를 보여준다.
참고로 의존성 트리에 관한 지식은 빌드 시 디버깅에 도움이 될 것 같다.
한편 리액트가 이러한 트리를 비교하고 갱신하는 핵심 메커니즘, Reconciliation(재조정)의 동작 원리는 별도의 글에서 써보겠다.
