From f02cbfdf9fe92114e5817956837104f8ba064500 Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Tue, 3 Dec 2024 00:06:04 +0900 Subject: [PATCH 1/2] =?UTF-8?q?Create=20=EC=83=81=EB=B2=94.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\203\201\353\262\224.md" | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 "\354\261\225\355\204\260_12/\354\203\201\353\262\224.md" diff --git "a/\354\261\225\355\204\260_12/\354\203\201\353\262\224.md" "b/\354\261\225\355\204\260_12/\354\203\201\353\262\224.md" new file mode 100644 index 0000000..0d29680 --- /dev/null +++ "b/\354\261\225\355\204\260_12/\354\203\201\353\262\224.md" @@ -0,0 +1,95 @@ +# 챕터 12 리액트 디자인 패턴 + +## 고차 컴포넌트 (HOC) +- 다른 컴포넌트를 인자로 받아 새로운 컴포넌트를 반환하는 컴포넌트 + +### 장점 +- 재사용하고자 하는 로직을 한 곳에 모아 관리 가능 => DRY 유지, 관심사 분리 가능 + +### 단점 +- prop 이름 충돌 가능성 => 어떤 고차 컴포넌트가 어떤 prop 제공하는지 파악하기 어려워 디버깅이 어려울 수 있음 + +> 이것만 단점으로 꼽는다고?! 복잡성과 트리 깊이 문제가 단점이라 생각 + +## 렌더링 Props 패턴 +- JSX 요소를 반환하는 함수 값을 가지는 컴포넌트 prop + +```js +function Input(props) { + const [value, setValue] = useState(''); + return ( + <> + setValue(e.target.value)} /> + {props.render(value)} + + ); +} + +export default function App() { + return ( +
+

Temperature Converter

+ ( + <> + + + + )} + /> +
+ ); +} +``` + +> 상태 끌어 올리기 예제가 아주 적절했음, 컴포넌트 자식으로 함수 전달하는 예제도 굿 + + +### 장점 +- 여러 컴포넌트 사이에서 로직과 데이터 쉽게 공유 가능 +- 재사용성 높이기 +- 애플리케이션 로직과 렌더링 컴포넌트 분리 가능 + +### 단점 +- 받은 데이터를 변경할 필요가 없는 렌더링에 치중한 컴포넌트에만 사용 가능 + +> 개인적으론 코드 가독성 떨어진다 생각, 가끔 유용하게 쓰일 떄 있을 것 같음 + + +## hook의 장단점 + +### 더 적은 코드 라인 수 +- hook을 사용하면 코드를 라이프사이클 별로 나누지 않고 관심사 및 기능별로 그룹화 가능 +- 코드 길이도 줄일 수 있음 + +### 복잡한 컴포넌트 단순화 +- 클래스 컴포넌트는 관리 어려움, 핫 리로딩과 함께 사용하기 힘듦, 코드 경량화 어려움 +- 함수 컴포넌트는 hook이 쉽게 도와줌 + +### 상태 관련 로직 재사용 +- 자바스크립트 클래스는 여러 단게에 걸친 상속 때문에 전체적인 복잡성을 높임 +- hook은 클래스 작성 안하고 기능 사용 가능 + +### UI에서 분리된 로직 공유 +- 클래스 컴포넌트는 UI와 무관한 로직을 추출하고 공유할 방법이 없었음 => 그래서 고차 컴포넌트, 렌더링 props같은 복잡한 방법 동원함 +- hook 등장 이후 자바스크립트 함수로 추출할 수 있게 되고 문제 해결 + +## 로더블 컴포넌트 +loadable-components 라이브러리는 SSR 환경에서 Suspense를 대체할 수 있는 좋은 방법 +> react 18부터 SSR환경에서도 Suspense 사용할 수 있다고 적혀있는데 굉장히 제한적임 +> Suspense 자체에 데이터 페칭 매커니즘이 없어서 tanstack-query에 의존하지 않으면 사용 못함 ㅋㅋ +> SSR 환경에서 suspense 사용? => next.js 아니면 못함 ㅅㄱ + +## PRPL 패턴 +- push: 중요 리소스 푸쉬해서 서버 왕복 횟수 최소화, 로딩 시간 단축 +- render: 최대한 빠르게 렌더링 (TTI 줄여 초기 사용자 경험 개선하기) e.g SPA 에서 초기에 필요한 js 번들만 로드하기 +- pre-cache: 초기 화면 렌더링 끝난 후, 사용자가 방문할 가능성 높은 경로와 리소스를 사전에 캐시하기 e.g service worker 사용 +- lazy-load: 초기 화면에 필요하지 않은 리소스(이미지, 비동기 JS 모듈 등)를 나중에 로드 e.g Intersection Observer API를 사용해 사용자 화면에 나타나는 시점에 이미지 로드, React.lazy와 Suspense로 필요한 컴포넌트를 동적으로 로드 + + +## 리스트 가상화 +한번에 수천개의 목록 요소를 렌더링하여 초기 렌더링 속도 저하 또는 스코롤 성능 저하를 유발하는 대신 가상화는 사용자에게 보이는 항목만 렌더링 시킴 + +> 실제로 무한 스크롤로 이루어진 페이지에서 이미지와 데이터가 DOM에 계속 쌓이다보면 점점 느려지는 경우가 있음 +> 무신사는 virtuoso, 오늘의집은 예전에는 react-virtualized 쓰다가 최근에 virtuoso로 갈아탄듯함 [오늘의집 무한스크롤 개발기](https://www.bucketplace.com/post/2024-09-11-virtualizedlist-%EB%AC%B4%ED%95%9C%EC%8A%A4%ED%81%AC%EB%A1%A4-%EB%A6%AC%EC%8A%A4%ED%8A%B8-%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81-%EA%B0%9C%EB%B0%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0/) + From 004b1472e46ea2256efe0808ff19de2441695e9c Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Tue, 3 Dec 2024 00:50:28 +0900 Subject: [PATCH 2/2] =?UTF-8?q?Create=20=EC=83=81=EB=B2=94.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\203\201\353\262\224.md" | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 "\354\261\225\355\204\260_13/\354\203\201\353\262\224.md" diff --git "a/\354\261\225\355\204\260_13/\354\203\201\353\262\224.md" "b/\354\261\225\355\204\260_13/\354\203\201\353\262\224.md" new file mode 100644 index 0000000..118fda8 --- /dev/null +++ "b/\354\261\225\355\204\260_13/\354\203\201\353\262\224.md" @@ -0,0 +1,58 @@ +# 챕터 13 렌더링 패턴 + +## 핵심 웹 지표 +- TTFB: 클라이언트가 페이지 콘텐츠의 첫번째 바이트를 받는데 걸리는 시간 +- FCP: 페이지 이동 후 브라우저가 콘텐츠의 첫 부분을 렌더링하는데 걸리는 시간 +- LCP: 페이지의 주요 콘텐츠를 로드하고 렌더링하는데 걸리는 시간 +- TTI: 페이지 로드 시작부터 사용자 입력에 빠르게 응답할 수 있을 때 까지 걸리는 시간 +- CLS: 레이아웃 변경 방지 위한 시각적 안정성 측정 +- FID: 사용자가 페이지와 상호작용한 시점부터 이벤트 핸들러가 실행될 수 있는 시점까지의 시간 + +## 클라이언트 사이드 렌더링(CSR) +- 모든 UI가 클라이언트에서 생성됨, 전체 웹 어플리케이션이 처음 요청 시에 모두 로드 됨 +- SPA 구축할 수 있게 함 + +### 단점 +- 초기 큰 자바스크립트 번들을 만들도록 해서 페이지의 FCP, TTI 증가 시킴 + +## 서버 사이드 렌더링(SSR) +- HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레이션 함 + +## 정적 렌더링(Static Rendering) +- 전체 페이지의 HTML을 빌드 시점에 미리 생성함 + +## 점진적 정적 생성(ISR) +- 정적 렌더링 + stale-while-revalidate 전략을 사용한 캐시 재검증 + +## 스트리밍 SSR + +> SSR 할 때 데이터 패칭 때문에 TTFB가 오래 걸림 +> => 리액트는 서버에서 renderToString 메서드 사용하는데 동기 메서드라 메인 스레드 점유 하니까 데이터 패칭할때까지는 화면에 아무것도 보여줄 수가 없네; +> => 이를 위해 비동기 처리 메서드 등장 (renderToPipableStream) +> +> next.js app router 사용하면 streaming ssr이 기본 적용! +> +> 데이터 패칭하는 컴포넌트를 Suspense로 감싸면 그 영역 바깥이 먼저 pre-rendering 되고 데이터 패칭과 렌더링을 번갈아가면서 청크 단위로 html에 내려보내줌 + +streaming ssr 공부할 때 좋았던 레퍼런스 +> [SSR의 기쁨과 슬픔: 렌더링의 변화의 흐름을 통해 알아보는 SSR과 Streaming SSR | 인프콘2023](https://www.youtube.com/watch?v=hPyyFu3lrEg&t=2080s) +> [[Dev Dive_ Frontend Day] 스트리밍 SSR 딥 다이브](https://www.youtube.com/watch?v=9xl9X2pfHeI&t=1835s) + +## 엣지 렌더링 + +> edge function은 최소한의 런타임 환경에서 동작하기 때문에 라이브러리 거의 못씀. e.g) axios, 라이브러리 내에서 사용한 web api가 edge function에서 지원하지않는 api라면 사용 불가 +> 왜? serverless function(e.g lambda)의 한계점인 콜드 스타트를 해결하기 위해 아예 지원하는 api를 줄여버림 +> 여담으로 콜드 스타트를 완화하기 위한 방법들이 많긴 함. 하지만 여전히 엣지 렌더링은 좋음 + +### 내가 생각하는 장점 +- 사용자와 가까운 곳에서 코드 실행 +- 실 서버까지 왕복 안함 +- 일정하고 짧은 반응 시간 가능 + +### 내가 생각하는 단점 +- 공짜겠음? ㅋㅋ + +## 하이브리드 렌더링 +- next.js app router 환경에서 페이지마다 ISR, SSR, CSR 등 하이브리드 렌더링이 가능 + +