알게된 것
- '렌더링'이라는 단어로 머리속에 혼재되어 있던, 브라우저 렌더링과 리액트 렌더링을 구분하여 생각할 수 있게 되었다.
- 리액트 렌더링을 수행하는 쪽에 따라 CSR과 SSR로 구분하여 생각할 수 있게 되었다.
- hydrate 시에 브라우저 콘솔에 발생한 경고의 이유를 알게 되었다.
리액트를 이용해서 프론트엔드 개발을 할 때, 리액트 렌더링이 어느쪽에서 수행되는지를 기준으로 나눠볼 수 있다.
-
클라이언트사이드 렌더링(CSR)
-
서버사이드 렌더링(SSR)
단일 페이지 어플리케이션(SPA)의 등장
SPA 등장 이전의 멀티 페이지 어플리케이션은 서비스 내에서 페이지 전환(라우팅) 시, 이동하려는 페이지에 대한 HTML 파일을 새로 가져와 브라우저에서 렌더링을 해야 했다.
이로 인해, 이동할 때 사용자 경험이 좋지 않았다. (다음 페이지에 대한 HTML을 받아 렌더링을 하기 전까지, 빈 화면이 노출)
액자에 그림을 바꿔서 걸 때, 이전 그림을 빼고 다음 그림을 넣는 동안 액자 뒷면이 그대로 노출 되는 것
모바일 앱과 유사한 사용자 경험을 제공하기 위해 자바스크립트 코드를 사용하여, 유저 인터렉션에 따라 DOM 구조를 수정하는 방식을 도입하고자 함.
동작 방식
SPA는 단일 페이지(HTML)로 구성된 앱으로, 초기 페이지 요청 시 함께 받은 자바스크립트 코드를 이용하여 렌더링 및 리렌더링을 수행한다.
액자에 그림을 바꾸기 위해, 그려져있던 그림을 지우개로 지우고 새로 그리는 방식
단점
첫 페이지 요청 시, 많은 양의 자바스크립트 코드를 다운로드해야 하므로 초기 로딩 시간이 길어진다.
액자를 두고, 첫 그림을 가져올 때 그림을 그릴 빈 도화지를 가져오고 그림을 그릴 도구들을 가져온 후에 직접 그려야 함.
단점 해결 방안
-
코드 스플리팅과 지연 로딩
필요한 코드를 필요한 시간에 받도록 하여, 로딩 시간을 줄일 수 있음그릴 수 있는 그림을 모두 그릴 수 있도록 여러 도구(연필, 물감, 크레파스 등)를 처음부터 준비하지 않고, 지금 보려는 그림을 그릴 도구만 준비하는 것.
-
서버사이드 렌더링
페이지 요청 시, 서버에서 해당 페이지에 대한 HTML을 렌더링한 후 클라이언트로 전달빈 도화지를 받지 않고, 그림이 그려진 도화지를 받는 것.
서버사이드 렌더링
과정
서버에서 요청받은 페이지에 대해 HTML을 렌더링한 후, 클라이언트에 전달한다.
클라이언트에서는 전달 받은 HTML에 대해 Hydration이 수행된다.
리액트가 클라이언트 측에서 실행되어, 정적인 HTML에 동적인 기능을 추가하는 것을 Hydration이라고 한다.
이 과정에는 이벤트 리스너의 등록, 리액트 컴포넌트의 상태 관리 등이 포함되어, 사용자와의 인터렉션이 가능한 동적인 페이지로 전환된다.
추가 설명
-
서버사이드에서 리액트 컴포넌트를 렌더링할 때,
ReactDomServer.renderToString()이라는 메서드를 사용한다.
정적 HTML 마크업을 생성한다. -
클라이언트 사이드에서 Hydration을 수행할 때는
ReactDOM.hydrate()메서드를 사용한다.
정적 HTML 마크업에 리액트 이벤트 핸들러를 연결하고, 리액트 상태 관리 및 생명주기 메서드 등을 활성화한다. -
Hydration시, 서버에서 생성한 마크업과 연결하려고 하는 컴포넌트를 렌더링했을 때의 마크업이 다르면 '경고'가 발생하고, 클라이언트사이드 렌더링으로 전환된다.
서버사이드 렌더링에 이어 추가 렌더링이 발생하게 될 수 있음.
