여기서 Stream 이란 큰 데이터를 작은 단위인 chunk로 쪼개서 서빙할 수 있는 node의 자료구조 입니다.
그렇다면 장점은 ???
이로서 저희 서비스는 다음과 같은 장점을 얻게 되었습니다.
초기 로딩 성능 향상됩니다. 서버에서 React 컴포넌트를 HTML 문자열로 렌더링하여 클라이언트에 전송함으로써, 브라우저가 JavaScript를 다운로드하고 실행하기 전에 초기 콘텐츠를 빠르게 표시할 수 있습니다.
검색 엔진에(SEO) 친화적입니다 : 서버에서 렌더링된 HTML은 검색 엔진 크롤러가 쉽게 읽을 수 있어, 웹 페이지의 검색 엔진 노출도를 높입니다.
3. 사용자 경험 향상을 향상시킵니다: 사용자는 초기 콘텐츠를 더 빨리 볼 수 있어, 특히 느린 네트워크 환경에서 사용자 참여도를 유지하는 데 도움이 됩니다. (참고로 이벤트루프 글을 보셨으면 아시겠지만 초기 스크립트(js파일)가 없으면 렌더링이 더 빠르게 된답니다. 다들 아시죠? )
그렇다면 단점은???
이로서, 저희 서비스는 다음과 같은 단점을 얻게 되었습니다.
1. 서버에서는 브라우저 API를 사용할 수 없습니다. 즉 window와 document, localhost를 사용하지 못합니다. 프론트엔드 개발자들은 이 때문에 골머리가 아플 수도 있습니다.
2. 서버에서는 컴포넌트 상태와, 생명주기를 사용할 수 없습니다. 즉 클라이언트에서 로딩되기 전까지 훅이나 이벤트가 동작하지 않습니다.
왜 냐구요 ? react server API 이것들의 결과물엔 JS가 없어요 단지 HTML만 존재할 뿐입니다. 그러면 어떻게 클라이언트에서 JS 파일을 읽으란 말입니까 ?
이 외에도 많은 react/server API가 존재하지만 중요한 두 가지만 소개하고 넘어가겠습니다.
그것을 해결해주는것이 바로 Hydration입니다.
Hydration 이란?
목마른 우리 String 또는 (ReadableStream)에게 물(JS)을 줘서 목마름을 해소 시켜 주는 과정이 되겠습니다.
그런데 이 과정이 그렇게 호락호락하지 않습니다. 말만 들어도 어렵죠 HTML에 어떻게 JS를 넣는다는거야 ..
이는 사용자 경험을 위해서 중요합니다. 사용자는 서버에서 만들어진 HTML을 자바스크립트 코드가 로드될 때까지 둘러보게 됩니다. 앱의 로딩을 더 빠르게 하기 위해 서버는 일종의 신기루로서 React 결과물인 HTML 스냅샷을 만들어 보여줍니다. 갑자기 다른 컨텐츠를 보여주게 되면 신기루가 깨져버리게 됩니다. 이런 이유로 서버에서 렌더링한 결과물과 클라이언트에서 최초로 렌더링한 결과물이 같아야 합니다.
React는 Hydration 오류에서 복구됩니다, 하지만 다른 버그들과 같이 반드시 고쳐줘야 합니다. 가장 나은 경우는 그저 느려지기만 할 뿐이지만, 최악의 경우엔 이벤트 핸들러가 다른 요소Element에 붙어버립니다.
정리하자면 hydration이 일치하지 않으면 !!!
서버에서 사전으로 렌더링 된 결과물과 리액트에서 hydration한 결과물이 다르면 신기루가 깨져요. 깜빡이면서 다른 화면이 렌더링 되겠죠 ? (즉 전혀 다른 초기 화면이 렌더링 될것이다.)
최악의 경우 이벤트 핸들러가 다른 element에 붙을 수도 있습니다.
불일치가 일어나면 그냥 CSR로 바뀌어 버립니다. ( 서버를 사용하는 이유가 사라집니다. )
hydration 코드 까보기
지금 부터 두루뭉실한 hydration 개념을 코드로 직접 hydration해 봅시다. ( ㅋㅋ )
Remix를 이용해서 리액트 풀스택 프레임워크 프로젝트를 생성해봅니다. 그러면 아래와 같은 파일을 볼 수 있습니다.
이 파일은 클라이언트 도입부를 담당하는 파일인데요, 코드를 살펴봅시다.
remix : entry.client.ts
import { RemixBrowser } from "@remix-run/react";
import { startTransition, StrictMode } from "react";
import { hydrateRoot } from "react-dom/client";
startTransition(() => {
hydrateRoot(
document,
<StrictMode>
<RemixBrowser />
</StrictMode>
);
});
startTransition : 파이버에 우선순위가 낮은 트랜지션(콜백함수)을 추가한다. hydrateRoot : 하이드레이션 루트를 만든다. 여기서는 document 객체와 RemixBrowser를 인자로 넣었다.
export function hydrateRoot(
container: Document | Element,
initialChildren: ReactNodeList,
options?: HydrateRootOptions,
): RootType {
if (!isValidContainer(container)) {
throw new Error('Target container is not a DOM element.');
}
// 하이드레이션 초기화 시, DEV 모드 에러 발생 시, 에러를 발생시킵니다.
warnIfReactDOMContainerInDEV(container);
if (__DEV__) {
if (initialChildren === undefined) {
console.error(
'Must provide initial children as second argument to hydrateRoot. ' +
'Example usage: hydrateRoot(domContainer, <App />)',
);
}
}
- // hydration option 처리
- // ...중략
- // hydration root를 만든다.
- // 이때 서버에서 만든 string과 HTML을 비교한다.
const root = createHydrationContainer(
initialChildren,
null,
container,
ConcurrentRoot,
hydrationCallbacks,
isStrictMode,
concurrentUpdatesByDefaultOverride,
identifierPrefix,
onUncaughtError,
onCaughtError,
onRecoverableError,
transitionCallbacks,
formState,
);
- // 이 하이드레이션을 root로 설정합니다.
markContainerAsRoot(root.current, container);
- // 모든 이벤트 리스너 부착
listenToAllSupportedEvents(container);
- // HydrationRoot 객체 리턴
return new ReactDOMHydrationRoot(root);
}
간단하죠 ? 리액트 측에서도 추상화를 아주 잘 해놔서 읽기가 매우 쉽습니다.
hydrationRoot 함수
hydrationRoot의 다양한 콜백 옵션을 처리합니다.
리액트컴포넌트와 초기 HTML (서버에서 렌더링한 결과물)을 이용해서 루트를 생성합니다.
리액트 루트 컴포넌트에 이밴트 리스너를 부착합니다.
hydrationRoot를 반환합니다. startTrasition 함수
hydrationRoot를 리액트 파이버 작업단위인 트랜지션에 넣습니다.
리액트컴포넌트와 초기 HTML (서버에서 렌더링한 결과물)을 이용해서 루트를 생성합니다.
그렇다면 createHydrationContainer는 어떻게 동작할까요? 이는 reconciler 패키지에 있습니다.
beginWork() {
// current를 업데이트 시키는 과정
// 하이드레이션을 하는 과정에서 dom에 id를 부착
//...
.
.
.
// 조건별로 업데이트하는 로직 시작
//...
case HostComponent:
return updateHostComponent(current, workInProgress, renderLanes);
//...
}
export function listenToAllSupportedEvents(rootContainerElement: EventTarget) {
. // rootContainerElement 마킹이 되어 있지 않으면
if (!(rootContainerElement: any)[listeningMarker]) {
// 최적화를 위해서 마킹
(rootContainerElement: any)[listeningMarker] = true;
// 모든 네이티브 이벤트를 부착한다.
allNativeEvents.forEach(domEventName => {
// selectionchange은
// 버블링이 일어나지 않기 때문에 document 환경에서 부착한다.
if (domEventName !== 'selectionchange') {
if (!nonDelegatedEvents.has(domEventName)) {
listenToNativeEvent(domEventName, false, rootContainerElement);
}
listenToNativeEvent(domEventName, true, rootContainerElement);
}
});
const ownerDocument =
(rootContainerElement: any).nodeType === DOCUMENT_NODE
? rootContainerElement
: (rootContainerElement: any).ownerDocument;
if (ownerDocument !== null) {
// selectionchange 또한 중복처리를 해준다.
// but it is attached to the document.
if (!(ownerDocument: any)[listeningMarker]) {
(ownerDocument: any)[listeningMarker] = true;
listenToNativeEvent('selectionchange', false, ownerDocument);
}
}
}
}
리액트에서 이벤트를 다루는 방법
rootContainerElement에 allNativeEvents (미리지정된 이벤트 배열) 을 반복하면서 부착시켜 이벤트를 위임시킨다.
리액트에서는 직접 node element에 이벤트를 붙이는게 아니라 루트 컴포넌트에서 모든 이벤트를 위임해서 처리한다.
이를 통해 리액트 컴포넌트 트리 수준으로 이벤트가 격리되어 이벤트 버블링을 막을 수 있다.
즉 리액트에서는 루트 컴포넌트에서 모든 네이티브 이벤트를 위임 처리해서 부착시켜 왔던것입니다. ( 진짜 몰랐다. )
