진행중인 사이드 프로젝트에 React의 server component 를 도입하다보니 여러 문제점들도 나타나고 쉽지 않아 애를 먹는 도중에, 이와 관련된 좋은 포스팅 글이 있어서 요약해보고자 합니다.

참고문헌

https://www.mux.com/blog/what-are-react-server-components

https://ykss.netlify.app/translation/everything_i_wish_i_knew_before_moving_50000_lines_of_code_to_react_server_components/
(친절하게 번역해주신 포스팅 입니다)

요약

RSC 가 도입되는 이유는?

• 기존 SSR, SSG 방식의 경우 서버에서 한 페이지 내 모든 컴포넌트를 렌더링 한 뒤, 여기에 더해 하이드레이션을 위해 컴포넌트들을 클라이언트에 스트리밍 해야 합니다. 서버측의 렌더과정이 지연될 수록 속도도 느려지게 되고, js 번들 사이즈 역시 커질 수 있습니다.

• 서버 컴포넌트를 지원하는 프레임워크는 코드가 실행되는 위치를 정의할 수 있는 방법을 제시합니다. 즉, 서버에서만 실행되어야 하는 컴포넌트를 알 수 있는것이죠.

• 이렇기에 클라이언트에 보내야 하는 자바스크립트의 코드 양을 줄일 수 있습니다.

• 또한 서버 컴포넌트는 서버에서 직접 데이터를 호출할 수 있습니다. 이는 페이지 수준에서 전체 데이터를 fetching 한 다음 필요한 컴포넌트에 props 로 전달하는 과정보다 더 효율적일 것입니다.

이와 달리 RSC의 단점은?

• CSS-In-JS를 사용할 수 없다고 합니다.. ㅜㅜ

• React Context 는 클라이언트 컴포넌트에서만 사용 가능하다고 합니다.

• 유연한 특징을 지니고 있기에 반대로 복잡성을 유발할 수 있어서 아직 개발작업시 익숙치 않아 어려움을 줄 수 있습니다.

• 서버에서 실행되는 것과 클라이언트에서 실행되는 것에 대한 이해가 필요하고, 하이드레이션에 대한 이해, 코드의 복잡성을 관리해야하는 비용 등이 단점으로 여겨질 수 있습니다.

Next.js 13 version app routing 를 활용하여 RSC 사용해보기

• app 하위 컴포넌트들은 기본적으로 모두 서버 컴포넌트입니다.

• 클라이언트에서는 서버에서 컴포넌트가 렌더링되어 전달될때동안 React 의 suspense 를 활용하여 fallback 을 표시하고 있을 수 있습니다.

• 상단에 'use client' 지시어를 작성하면, 컴포넌트를 클라이언트로 전송하게 됩니다. 또한 이러한 클라이언트 컴포넌트가 import 하는 모든 컴포넌트들도 다 클라이언트로 전송이 됩니다.

• 즉, 클라이언트 컴포넌트 역시 서버에서 렌더링이 되며, 차이점이라면 하이드레이션을 위해 컴포넌트가 클라이언트로 전송된다는 부분입니다. (기존 SSR 과 같습니다)

기존 프로젝트에 점진적으로 적용해보기

• 최상위 루트 컴포넌트에 'use client' 지시문을 추가합니다.

• 이후 점자적으로 'use client' 지시문을 자식 컴포넌트로 이동시켜간다.

• 느린 데이터를 스트리밍 할 때는 suspense로 래핑해줍니다

• 클라이언트 컴포넌트에서 서버 컴포넌트를 전달할 때는 props 로 전달하는것이 가능합니다.