배경
※ 다른 거 하면서 듣느라 오역 있음
수염 멋있게 기른 Dan형이 발표함.
S/W개발에서 Cheap/Fast하게 만들면 Good이 안 나오고 Good/Fast하게 만들면 Cheap하지 않다는 얘기를 함.
Spotify를 예시를 들며, 자신이 spotify 목업을 만든다면 위 이미지처럼 만들겠다고 선언함.
위 화면의 컴포넌트는 총 3개의 data fetching이 일어나게 되는데(디테일, 탑트랙, 디스코그래피) 이렇게 되면 각각의 fetching마다 request/response를 기다려야 돼서 비효율적임
그래서 이런 문제를 해결하려고 서버 컴포넌트를 만들었음.
하지만 지금 당장 추가하지는 않을 거임. 그래도, 우리의 아웃풋을 공유하고 싶음
영상의 12분전까지는 문제 상황에 대한 예시(만들게 된 배경)을 설명하고 그 이후는 데모 시연, recap이 있음
데모 시연
데모에서는 두 개의 컴포넌트를 중점으로 보여줄 거임.
먼저 .server.js 확장자가 붙여진 파일의 컴포넌트로, 리액트한테 이건 서버컴포넌트라고 말함.
서버 컴포넌트 => 서버에서만 이 컴포넌트를 렌더링한다는 것을 말하는 것
.client.js 확장자를 붙여서 리액트에게 '이건 클라이언트상에서만 렌더링 될거야'라고 말하는 것
잠시 다른 걸 보자면, 클라이언트 컴포넌트는 react-fetch라고 하는 fetch API를 래핑한 리액트 라이브러리를 사용함.
react-fetch의 흥미로운 점은 synchronous하게 작동되서 useEffect같은 걸로 래핑을 안 해도 됨.
이후, 웹팩이 번들링한 결과물을 보면 .server.js가 빠져있음 음??????
장점들
연구중인 것
언제 쓸까?
데이터 패칭, 전처리(pre-processing) => 서버 컴포넌트
인풋과의 빠른 interaction => 클라이언트 컴포넌트
정리
- 서버 컴포넌트 코드는 클라이언트로 일절 전송되지 않음.
- 서버 컴포넌트는 트리에서 바로 백엔드로 access하게 해줌.
- 서버 컴포넌트는 클라이언트 상태가 유지된 채로 refetch됨.
- 덕분에 클라이언트는 번들 용량이 줄어들고, 데이터도 빠르게 불러올 수 있어서 좋음.
- 클라이언트 코드 스플리팅이 자동으로 됨.
이...이게 뭐야..
자료들
여기에 모든 내용이 들어 있다. 57분19초짜리 영상
영어로 짧막하게 정리도 되어 있다. 영문판 내용정리
그외에 궁금한건 여기로가면 되니 참고.
wow...
새로운 바람이 불겠군요