240315(금)
🌱 성장일지 9.0
책 행복한 이기주의자(웨인 다이어)의 내용에 자극받아 시작하는 소박한 성장기록
- 살아있는 꽃과 죽은 꽃은 어떻게 구별하는가?
- 성장하고 있는 것이 살아 있는 것이다.
- 생명의 유일한 증거는 성장이다!
🧩 (10.0) 매일 공부한 것, 새롭게 알게 된 것, 간단하게라도 작성하고 싶은 것을 주관적인 생각과 함께 편하게 작성하자! 그리고 그 중에서 괜찮은 내용을 잡동사니에서 자세히 다루자!
🔨 개발관련
GraphQL
- REST API: 서버에서 정해놓은 URL(엔드포인트)로 요청을 보내고, 서버는 그에 맞는 응답을 보내주는 방식
- GraphQL: 클라이언트가 요청한 데이터의 형태를 정의하고, 서버는 그에 맞는 데이터를 응답해주는 방식
GraphQL의 장점
- Over-fetching: REST API에서는 요청한 데이터보다 많은 데이터를 받아오는 경우가 있다. GraphQL은 요청한 데이터만 받아올 수 있다. 즉, 데이터 전송량을 줄일 수 있다.
- Under-fetching: REST API에서는 하나의 화면을 구성하기 위해 여러 번의 요청을 보내야 할 때가 있다. GraphQL은 하나의 요청으로 여러 데이터를 받아올 수 있다. 즉, 요청 횟수를 줄일 수 있다.
- 하나의 엔드포인트로 모든 요청을 처리할 수 있다.
그러나 언제나 GraphQL이 좋은 것은 아니다. 데이터가 많은 경우에는 REST API가 더 효율적일 수 있다. 또한, GraphQL은 서버에 부하를 줄 수 있다.
우리가 흔히 가는 마라탕 식당(재료가 진열되어있기도 하고 가게에서 조합해놓은 메뉴가 있기도 한 식당)에 비유하면 이해가 편하다.
- 가게 직원: 서버
- 메뉴판에 있는 메뉴에서 골라서 주문(요청)하는 것: REST API
- 내가 원하는 재료를 직접 하나하나 골라서 주문(요청)하는 것: GraphQL
Apollo
GraphQL은 REST API와 같이 어떤 구현체가 아니라 단순히 스펙이다. 그래서 GraphQL을 사용하기 위해서는 서버와 클라이언트쪽에서 이 스펙에 맞는 구현체(라이브러리 혹은 프레임워크)를 사용해야 한다. GraphQL 공식 홈페이지에 가면 서버와 클라이언트 각각에 대한 여러 구현체를 살펴볼 수 있다. 그 중에서 Apollo는 가장 유명한 구현체 중 하나이다. Apollo Client와 Apollo Server가 있다. 설정이 쉽고 사용하기 간편하며 다양한 기능을 제공한다.
TypeScript
- any보단 unknown을 사용하자. any는 어떤 값이든 할당할 수 있고 어떤 곳에든 할당될 수 있다. unknown은 어떤 값이든 할당 할 수 있지만, 어떤 곳에든 할당될 수 없다. 즉, unknown은 any보다 더 안전하다. 또한, 이를 통해 개발자에게 type assertion이나 type guard를 사용하도록 유도할 수 있다!!!
- 암묵적 any는 이후 실행되는 js 로직에 따라서 evolve(진화)하여 특정 타입을 갖게 될 수 있다. 장점처럼 보이지만, 되려 타입 안정성을 해칠 수 있기 때문에, 언제나 명시적으로 타입을 지정하는 게 좋다.
React
- 이전에는 렌더링 프로세스를 Stack으로 관리했지만, 이제는 Fiber로 관리한다. Fiber는 렌더링 프로세스를 관리하는 알고리즘이다. 이전에는 렌더링 프로세스가 시작되면 끝날 때까지 다른 작업을 할 수 없었지만(동기적), Fiber는 렌더링 프로세스를 중단하고 다른 작업을 할 수 있게 해준다.(비동기적) 이를 통해 렌더링 프로세스를 더 세밀하게 관리할 수 있다.
- 리액트의 렌더링과 브라우저의 렌더링은 아예 아예 다른 말이니까 주의하자.
리액트의 렌더링
- 렌더 단계: Work In Progress Tree와 Current Tree를 비교하여 변경된 부분을 찾아낸다. 사용자에게 노출되지 않는 모든 비동기 작업을 처리한다.
- 커밋 단계: 변경된 부분을 실제 DOM에 반영한다. 동기식으로 일어나고 중단될 수 없다. 주의!!! 여기서 실제 DOM에 반영된다는 말이 브라우저의 렌더링이 일어나는 것이 아니다. 말 그대로 HTML이 트리구조로 정리된 DOM 객체에 변경된 값들이 반영된 것이다.(이 때까지도 사용자는 변경된 화면을 보지 못한다.)
- 페인트 단계: 브라우저의 렌더링 엔진이 변경된 DOM 객체를 화면에 그린다. => 리액트에서는 브라우저의 렌더링을 페인트라고 부른다.(마찬가지로 브라우저의 렌더링에서 레이아웃, 페인트, 합성을 말할 때 페인트와 헷갈리지 말 것!!!)
React Fiber 객체는 Element와 1:1 관계를 가지고 생성된다. 그리고 Fiber 객체에는 tag, key, type, pendingProps, memoizedProps 기타 등등 여러가지의 property로 해당 element의 렌더링 관련 정보를 담고 있다. 그리고 이러한 정보를 파탕으로 Fiber Reconciler가 렌더링 프로세스를 관리한다.
위의 내용을 기반으로 useLayoutEffect와 useEffect의 차이를 생각해보기
렌더 단계 - 커밋 단계 - useLayoutEffect - 페인트 단계 - useEffect의 순서로 일어난다. 즉, 커밋 단계에서 DOM을 변경하더라도 아직 페인트 단계(브라우저 렌더링)이 일어나지 않았고 그 전에 useLayoutEffect가 일어나기 때문에 렌더링 전에 DOM을 변경할 수 있다. 반면에 useEffect는 렌더링 후에 일어나기 때문에 렌더링 후에 DOM을 변경할 수 있다. 해서 useEffect에서 DOM을 변경하면 유저의 눈에 값이 바뀌는 게 보이지만, useLayoutEffect에서 DOM을 변경하면 유저의 눈에는 변경된느 게 보이지 않는다.
🥳 감정관련
앞으로 블로그에 최소 1일 ~ 최대 3일 간격으로 내가 공부한 내용 중 핵심(?)을 기록할 예정이다. 그런데 이게 옳은 방법인지는 잘 모르겠다... 누군가에게 보여줄 목적으로 카테고리를 잘 나눠서 정리하는 게 좋을지 지금처럼 나만의 아카이브 형태로 기록을 남기는 게 좋을지..! 우선은 후자의 방법이 내 장점을 잘 살리면서 블로그를 운영하는 것이라 생각해서 이 방법으로 진행해보려고 한다. 찾고 싶은 키워드나 내용을 검색할 수 있게 해두었으니 괜찮을 것 같다!
오늘은 금요일이라 그런지 쪼오금 해이했던 것 같아서 아쉽긴 하다. 이제 다음주부터 기대하고 기대하던 출근이라 그런지, 뭔가 더더더 많은 걸 준비하고 알고 가야할 것 같은..? 초조함이 드는 것도 있다. 잘하자.