개발 단계에서는 모든 것이 훌륭했지만 프로덕션 단계에서는 내 블로그 하단에서 의도하지 않은 일이 일어나고 있었습니다.
엉망이 된 UI
devtools의 Elements 탭을 조금 파헤쳐 원인을 밝혀냈습니다.
내 React 컴포넌트가 잘못된 지점에서 렌더링되었습니다!
개발 환경에서는, main 아래 나란히 두 컴포넌트가 렌더링 되었는데요.
<!-- In development, things are correct -->
<main>
<div class="ContentFooter">
Last updated: <strong>Sometime</strong>
</div>
<div class="NewsletterSignup">
<form>
<!-- Newsletter signup form stuff -->
</form>
</div>
</main>
운영 환경에서는, 상단 컴포넌트의 자식으로 컴포넌트가 렌더링 되고 있었습니다.
<!-- In production, things had teleported! -->
<main>
<div class="ContentFooter">
Last updated: <strong>Sometime</strong>
<div class="NewsletterSignup">
<form>
<!-- Newsletter signup form stuff -->
</form>
</div>
</div>
</main>
React의 서버 사이드 렌더링 컨텍스트에서 작동하는 방식에 대해 근본적인 오해가 있었습니다.
그리고 많은 React 개발자들이 이 오해를 공유하고 있다고 생각합니다!
그리고 그것은 꽤 심각한 결과를 초래할 수 있습니다.
문제 될 수 있는 코드들
위와 같은 렌더링 문제를 일으킬 수 있는 코드의 예는 다음과 같습니다.
문제를 발견하셨나요?
function Navigation() {
if (typeof window === 'undefined') {
return null;
}
// Pretend that this function exists,
// and returns either a user object or `null`.
const user = getUser();
if (user) {
return (
<AuthenticatedNav
user={user}
/>
);
}
return (
<nav>
<a href="/login">Login</a>
</nav>
);
};
이 튜토리얼은 서버 측 렌더링이 작동하는 방식을 이해하는 데 도움이 되도록 장막 뒤를 엿볼 것입니다.
이 코드의 로직이 문제가 될 수 있는 이유와
다른 접근 방식이 동일한 목표를 달성할 수 있는 방법을 살펴보겠습니다.
서버 사이드 렌더링 101
문제를 이해하려면
먼저 Gatsby 및 Next.js와 같은 프레임워크가 React로 구축된 기존 클라이언트 측 앱과 어떻게 다른지 조금 파고들어야 합니다.
create-react-app과 같은 것과 함께 React를 사용하면 모든 렌더링이 브라우저에서 발생합니다.
React는 페이지의 모양에 대한 그림을 만들고 많은 DOM 노드를 주입하여 그렇게 만듭니다.
모든 렌더링이 클라이언트(사용자의 브라우저)에서 발생하므로 이를 클라이언트측 렌더링이라고 합니다.
이 모든 작업에는 시간이 걸리며,
브라우저와 React가 마법을 사용하는 동안 사용자는 빈 흰색 화면을 보고 있어야 합니다.
유저에게 좋은 경험이 아닙니다.
똑똑한 사람들은 우리가 서버에서 렌더링을 할 수 있다면 사용자에게 완전한 형식의 HTML 문서를 보낼 수 있다는 것을 깨달았습니다.
이러면 브라우저가 JS를 다운로드, 구문 분석 및 실행하는 동안 볼 것이 있습니다.
이를 서버 사이드 렌더링(SSR)이라고 합니다.
서버 측 렌더링은 성능 향상이 될 수 있지만 문제는 작업이 여전히 주문형(on demand)으로 수행되어야 한다는 것입니다.
your-website.com을 요청할 때 React는 React 컴포넌트를 HTML로 변환해야 하며
유저는 기다리는 동안 여전히 빈 화면을 응시하게 됩니다.
사용자 컴퓨터가 아닌 서버에서 작업이 수행되고 있을 뿐입니다.
이것이 바로 Gatsby가 하는 일입니다(특정 설정에선 Next.js도요).
Yarn 빌드를 실행하면 사이트의 모든 경로에 대해 1개의 HTML 문서가 생성됩니다.
모든 페이지, 모든 블로그 게시물, 모든 스토어 아이템 - 각각에 대한 HTML 파일이 생성되어 즉시 제공될 수 있습니다.
그런데 이 모든게 서버 사이드 렌더링인가요?
불행하게도, 해당 용어는 실제로 다양한 의미로 사용됩니다.
기술적으로 Gatsby가 하는 일은 서버 사이드 렌더링입니다.
전통적인 서버 측 렌더링과 동일한 ReactDOMServer API를 사용하여 Node.js를 사용하여 React 앱을 렌더링하기 때문입니다.
하지만 제 생각에는 개념적으로 다릅니다.
"서버 사이드 렌더링"은 요청에 대한 응답으로 라이브 프로덕션 서버에서 실시간으로 발생하는 반면
이 컴파일 타임 렌더링은 빌드 프로세스의 일부로 훨씬 더 일찍 발생합니다.
어떤 사람들은 SSG라고 부르기 시작했습니다. 사람에 따라 "Static Site Generation" 또는 "Server-Side Generated"라고 합니다.
클라이언트의 코드
오늘날 우리가 개발하는 앱은 상호작용이 많고 역동적입니다.
사용자는 HTML과 CSS만으로는 달성할 수 없는 경험에 익숙해져 있습니다!
따라서 우리는 여전히 클라이언트 측 JS를 실행해야 합니다.
클라이언트 측 JS에는 컴파일 타임에 생성하는 데 사용되는 것과 동일한 React 코드가 포함되어 있습니다.
그것은 사용자의 장치에서 실행되며. UI를 만듭니다.
그런 다음 이를 document에 존재하는 HTML과 비교합니다.
이것은 rehydration(재수화)로 알려진 프로세스입니다.
rehydration은 render와 같은 것이 아닙니다.
일반적인 렌더링에서 프롭이나 상태가 변경되면 React는 차이점을 조정하고 DOM을 업데이트할 준비가 됩니다.
rehydration에서 React는 DOM이 변경되지 않는다고 가정합니다.
기존 DOM을 사용하려고 할 뿐입니다.
동적인 Section
코드로 다시 돌아갑시다.
const Navigation = () => {
if (typeof window === 'undefined') {
return null;
}
// Pretend that this function exists,
// and returns either a user object or `null`.
const user = getUser();
if (user) {
return (
<AuthenticatedNav
user={user}
/>
);
}
return (
<nav>
<a href="/login">Login</a>
</nav>
);
};
