이 컨퍼런스에서 React Server Component를 쓰는 사람이 얼마나 되는가? 1% 정도라고 말하고 싶다. 아마 새로 나왔기 때문이라고 생각한다. 내가 말하고 싶은 것은 RSC의 메커니즘에 대한 것이다.
일반적으로 사용하는 방법은 실제로 Next.js 또는 프레임워크를 사용하는 것입니다.
제가 이야기 하고 싶은 것은 메커니즘입니다. 왜냐하면 저는 엔지니어로서 높은 수준의 블랙박스 추상화를 받아들이는데 문제가 있었다. next.js를 사용한다면 그것이 어떻게 작동하는지 기본 메커니즘을 이해해야 합니다.
여기서는 React의 기본은 다루지 않을 것입니다. 이미 알고 있다고 가정할 것이다. 그리고 Server Action 또한 다루지 않을 것이다.
우리가 이야기 할 것은 이론적인 측면에서 서버 구성 요소(RSC)에 대해 그들이 해결하는 문제를 살펴본 다음 서버 구성 요소(RSC)를 구현하는 방법을 살펴볼 것이다.
렌더링은 실제로 서버 구성 요소 사이의 경계에 있다. 클라이언트 구성 요소(RCC)의 의미와 서로 어떻게 결합되는지 알아야 한다.
서버 구성 요소에 대해 조금 축소해서 이야기를 시작해보자.
React의 첫 번째 원칙 스타일은 웹 애플리케이션이 사용자 인터렉션 할 수 있도록 하는 소프트웨어라고 생각하고 있다.
버튼을 클릭하고 리액트는 정확하게 작동하지만 단순히 반응하는 것이 아니라 잘 반응하는 것이 중요하다. 빠르게 반응하는 것이 중요하다.
비싼 CPU 작업이 렌더링하고 있을 중 큰 목록을 렌더링하고 유저가 “a”를 입력했을 때 CPU가 어떤 작업을 수행하기 전에 즉각적으로 반응하는 것이 리액트의 목적이다.
따라서 일반적으로 웹 애플리케이션은 CPU에 종속된다는 의미이다. CPU에서 작업 중 CPU는 네트워크에도 바인딩되어 있으므로 데이터 호출에 때때로 사용자 인터페이스를 방해할 수 있다.
트위터는 전적으로 클라이언트 측에서 렌더링 되었기 때문에 여러 개의 스피너를 동시에 볼 수 있으며 이는 사용자 경험(UX)을 방해할 수 있다.
그렇기에 서버 사이드 렌더링이 정답이었다. 모든 리액트 컴포넌트를 서버 사이드에서 렌더링한 다음 HTML처럼 브라우저로 스트리밍 할 수 있다. 이렇게 스피너 문제를 해결하지만 세분화 수준은 이상적이지 않다.
서버 컴포넌트가 데이터 패칭에 대한 서스펜스에 대해 들어봤을 수 있다. 데이터 패칭이 기본적으로 문제가 된 이유는 대규모 JavaScript 번들의 문제를 해결하면서 시작되었다. 우리는 많은 JavaScript를 많이 제공하곤 했다. 전체 애플리케이션은 기본적으로 우리가 일부 서버에서 브라우저로 전송하는 JavaScript 였다. 브라우저는 JavaScript 파일을 다운로드하여 실행하고 애플리케이션은 대화형이 된다.
서버 렌더링은 마크업을 보낸 다음 JavaScript가 로드되도록 hydrating하여 문제를 해결한다. 서버 컴포넌트는 이후에 컴포넌트를 서버에서만 독점적으로 렌더링하여 더 많은 문제를 해결하였다.