From 839053ec042e00d73084f522968bda7737c9a455 Mon Sep 17 00:00:00 2001 From: hyesungoh Date: Tue, 3 Dec 2024 00:03:27 +0900 Subject: [PATCH 1/2] =?UTF-8?q?12=20=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\230\244\355\230\234\354\204\261.md" | 179 ++++++++++++++++++ .../\354\230\244\355\230\234\354\204\261.md" | 2 + 2 files changed, 181 insertions(+) create mode 100644 "\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md" create mode 100644 "\354\261\225\355\204\260_13/\354\230\244\355\230\234\354\204\261.md" diff --git "a/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md" "b/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md" new file mode 100644 index 0000000..494fc14 --- /dev/null +++ "b/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md" @@ -0,0 +1,179 @@ +# 리액트 디자인 패턴 + +## 리액트 소개 + +제곧내 + +## 고차 컴포넌트 + +- 장점 + - 재사용하고자 하는 로직을 한 곳에 모아 관리 + - 관심사 +- 단점 + - props에 대한 핸들링 (블랙박스) + - 파악하기 어려워짐 + +> hook이나 후술하는 렌더링 프롭 등 대체 가능한 패턴이 많다고 생각됨 +> 고차 컴포넌트가 핏한 해결 방법인 경험이 없음 + +## 렌더링 Props 패턴 + +```js +function Compo() { + return ( + + {value =>
{value}
} + + ); +} +``` + +- 장점 + - 여러 컴포넌트 사이에서 로직과 데이터를 쉽게 공유 (재사용성) +- 단점 + - hook으로 대체 가능 + > 코드의 추상화 수준이 좀 높아질 수 있다? 단점은 아니겠지만 .. + +## Hooks + +알잘딱 + +## 동적 가져오기 + +### 로더블 컴포넌트 + +서버 사이드의 Suspense의 대안 +https://www.npmjs.com/package/@loadable/component + +> 생각보다 다운로드 수가 높네용 + +> 18 이후부터 서버 사이드에서도 Suspense 동작 +> > 그럼에도 클라이언트에서만 하고 싶다면 https://suspensive.org/ko/docs/react/Suspense#%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%84-%ED%94%BC%ED%95%98%EA%B8%B0-clientonly + +## PRPL 패턴 + +- Push Render Pre-cache Lazy-load + +- Push + - 중요한 리소스를 효율적으로 푸시, 서버 왕복 횟수를 최소화해 로딩 시간을 단축 +- Render + - 초기 경로를 최대한 빠르게 렌더링 +- Pre-cache + - 자주 방문하는 경로의 에셋을 백그라운드에서 미리 캐싱 +- Lazy-load + - 자주 요청되지 않는 것은 지연 로딩 + +### HTTP + +- HTTP/1.1은 keep-alive 헤더를 통해 새로운 요청 전송 전까지 클라이언트와 서버 간의 TCP 연결을 유지하는 등 1.0에 비해 많은 개선점을 도입 + +- HTTP/1.1은 클라이언트와 서버 간 최대 6개의 TCP 연결만 가능했음 + - 그래서 마지막 요청이 오래 걸리면, 다른 요청을 전송할 수 없어 HOL Blocking이 발생해 로딩 시간을 증가시킬 수 있음 + - Head-of-line Blocking + +- HTTP/2는 양방향 스트림을 사용 + - 단일 TCP 연결을 통해 여러 개의 양방향 스트림을 만들어 클라이언트와 서버 간에 여러 개의 요청 및 응답 프레임을 동시에 전달할 수 있음 + +- HTTP/2는 서버 푸시라는 데이터 가져오기 방식을 도입 + - 매번 명시적으로 리소스를 요청하지 않고, 이런 리소스를 푸시하여 자동으로 추가 리소스를 전송할 수 있게 됨 + > 이게 먼소리여 + +```md +HTTP/1.1 (기존 방식) + +1. 피자를 주문합니다 +2. 피자가 도착합니다 +3. 피자를 보니 콜라가 필요해서 다시 주문합니다 +4. 콜라가 도착합니다 +5. 그러다 치킨 윙이 먹고 싶어서 또 주문합니다 +6. 치킨 윙이 도착합니다 + +이렇게 매번 필요한 것이 생길 때마다 새로운 주문을 해야 했습니다. + +HTTP/2 서버 푸시 (새로운 방식) + +1. 피자를 주문합니다 +2. 가게에서는 "아! 손님들이 보통 피자랑 콜라랑 치킨 윙을 같이 시키시더라"라고 생각하고 +3. 피자와 함께 콜라와 치킨 윙도 미리 보내줍니다 + +즉, 서버 푸시는 웹사이트가 "이 사용자가 곧 필요할 것 같은 파일들"을 미리 보내주는 똑똑한 시스템입니다. 예를 들어: + +- 웹페이지를 요청하면 +- HTML 파일과 함께 +- 곧 필요할 CSS, 이미지, JavaScript 파일들도 자동으로 보내줍니다 + +이렇게 하면 사용자가 일일이 요청하지 않아도 되니까 웹사이트 로딩이 더 빨라지죠! 🚀 + +> 이해 완 +``` + +- 서버 푸시는 HTTP 캐시를 인지하지 못함 + - 그래서 웹사이트 재방문 시에는 사용할 수 없음 + - 이를 위해 초기 로드 이후에 서비스 워커를 사용하여 해당 리소스를 캐시함으로써 클라이언트가 불필요한 요청을 하지 않도록 함 + +```md + +1. HTTP 캐시와 서버 푸시의 관계 + +중학생 철수가 문방구에서 장난감을 사는 상황으로 비유해볼게요: +첫 방문 시: +철수: "로봇 장난감 하나 주세요!" +문방구 아저씨: "여기 로봇이요! 아, 그리고 보통 애들이 건전지랑 스티커도 같이 사니까 이것도 드릴게요!" (서버 푸시) + +재방문 시: +철수: "어제 산 로봇이랑 똑같은 거 주세요!" +문방구 아저씨: "어! 철수야, 너 이미 건전지랑 스티커 있을 텐데... 근데 난 그걸 모르니까 또 줘버렸네..." + +2. 왜 서비스 워커가 필요할까? + +서비스 워커는 마치 철수의 '장난감 노트'같은 거예요: +📝 철수의 장난감 노트 (서비스 워커) +- 로봇 장난감 ✅ +- 건전지 ✅ +- 스티커 ✅ + +이제 철수가 다시 문방구에 갈 때: + +노트를 먼저 확인해서 "아, 이미 있는 거네!" +필요한 것만 달라고 할 수 있어요 + +정리하면: +HTTP 서버 푸시는 사용자의 브라우저에 뭐가 있는지 모르고 무조건 다 보내요 (비효율적) +서비스 워커는 브라우저에 뭐가 있는지 기록해두고, 필요한 것만 요청할 수 있게 해줘요 (효율적) +이렇게 서비스 워커가 똑똑한 메모장 역할을 해서, 불필요한 데이터를 또 받지 않아도 되는 거예요! 🎯 + +> 개쩐다 +``` + +> 저자가 브라우저 개발자라 그런지 이런건 빠삭한 느낌..? + +## 로딩 우선순위 + +- 에셋은 `rel='preload'` +- 자바스크립트 자체의 로딩을 최적화 -> `` 안에 `