리액트 기초

 

 

https://velog.io/@hyunjine/Thinking-in-React#reconciliation%EC%9E%AC%EC%A1%B0%EC%A0%95

 

 

그냥 위의 글 보고 공부한 거임

 

 

dom (document object model)

브라우저가 html(string)을 파싱해서 객체 형태로 만든 거임

 

 

html은 문자열임

문자열은 다루기 어려운데 이걸 다루기 쉬운 객체 형태로 바꿔주는게 dom임

프론트엔드 개발자는 이 dom을 조작해서 개발함

 

 

dom을 직접 조작하는 데 문제점

 

html 파싱해서 돔 트리 만들고 css 파싱해서 dom + css -> 렌더트리 ->  reflow -> 페인팅

 

dom 하나 수정될 때마다 dom 전체트리 변경사항 수정해야 됨

글자랑 위치 죄다 계산해야하는 거임 => 렌더링 부담감 큼

 

 

그래서

 

virturalDOM이 필요함

 

 

가상돔은 변경 사항만 받아서 차이점만 실제 돔에 전달함

diff 알고리즘을 사용하고 이걸 리액트에서는 reconciliation(재조정) 이라고 함

 

그럼 재조정은 실제 돔 바꿀 때 일어나는 일일까 버츄얼돔 바꿀 때 일어나는 일일까

답은 이 모든 과정을 재조정이라고 하는 거 같음

 

1. 상태가 업데이트 됨

2. 해당 컴포넌트는 업데이트가 필요하다고 표시함

3. 리액트는 감지하고 트리의 최상단부터 렌더 패스를 시작함

4. 업데이트가 필요한 애들을 보면 렌더링함

5. 이때 컴포넌트 자식들도 렌더링 됨 (재귀적으로 렌더링한다고 함)

6. 자식들 중에서는 전 값과 똑같은 컴포넌트가 있을 거임

7. 값이 변하지 않은 컴포넌트는 찐 dom에 반영 안 함

8. 그럼 어떻게 값이 변하지 않은 걸 아는지 => 바뀐 부분만 계산하는 diffing 사용

9. 값이 변한 돔만 dom에 반영함

10. 이게 reconsiliation 임

 

 

 

각각 8, 9번을 정의해보면

 

8. render phase 단계 (렌더 단계) : 버츄얼 돔 변경 사항 렌더링 + 찐 돔에 적용할 때 바뀐 부분만 계산

9. commit phase 단계 (커밋 단계) : 변경사항 찐 돔에 적용

 

임

 

쉽게 얘기하면

 

(렌더링 + 변경 사항 추리기) + (찐 dom 부분적으로 업데이트) = 재조정

 

 

---

 

+++ 추가

 

https://velog.io/@bangdori/React-18-Suspense%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90

 

https://velog.io/@chltjdrhd777/React-hydration%EC%9D%B4%EB%9E%80-root%EB%9E%80

 

https://m.post.naver.com/viewer/postView.naver?volumeNo=34886166&memberNo=59450302

-> 이 글이 도움 많이 됨

 

 

자바스크립트는 브라우저 위에서 동작하기 때문에

리액트도 제약을 받음

 

예컨대

 

스레드

브라우저는 싱글 스레드임

한번에 하나의 작업만 가능함

 

리액트도 여기에 종속됨

렌더링을 시작해서 화면을 완성할 때까지 실행을 멈출 순 없음 <= 이게 블로킹 렌더링

 

근데 리액트 18와서 이걸 해결해냄

 

동시성 기능 (concurrent features)

작업을 잘게 나누어서 context swtiching 함

 

그러니까 엄청 빠르게 왔다갔다 작업하는 거임

이러면 둘 다 동시에 일하는 것처럼 보임

 

이 기능을 활용하면 렌더링을 엄청 잘게 쪼개고, 상태 업데이트에 우선 순위를 둘 수 있음

 

 

대부분 리액트 라우터 보면 요렇게 감싸져 있는 거 보임

주로 로딩 스피너 쓰려고...

 

리액트 말로는 suspense는 단순 로딩스피너가 아니라고 함

이게 저 위의 설명한 걸 구현해줌

 

18 버전에 추가된거임 (올 말에 19버전 업데이트될 예정)

 

https://youtu.be/pj5N-Khihgc?si=48TpnosvR9V4ZFYo

여기에서 친절하게 알려줌

 

 

이런 페이지가 있음

 

 

comments가 페이지에서 가장 중요한 곳이자

엄청 비싼 api콜을 한다고 함 

 

이걸 화면에 그릴 때 몇 가지 선택지가 있을 거 같음

 

1. comment 데이터 받아오기 전까진 화면에 아무것도 안 그리기

=> blank page 구림

 

2. 다른 컴포넌트 먼저 그리고 패칭이 완료된다면 comment 컴포넌트 그리기

=> 페이지에서 comment가 제일 중요한 데 이걸 마지막에 데이터를 다 받고 마지막에 그리는 거 구림

=> 완벽한 페이지를 위해선 그래도 같은 포인트에 그리는 게 나음

 

그렇다면 왜 느릴까

=> 왜냐면 자바스크립트 파일 읽으면서

이걸 맞는 html에 결합하는데

이게 시간이 오래걸린다고 함

=> 이걸 영상에선 하이드레이션이라고 표현함 (근데 찾아보니 하이드레이션은 보통 ssr에서 말하는 거 같음, next.js 보면 html먼저 오고 다음에 css 입혀지는 걸 볼 수 있는데 이것도 비슷함, 자바스크립트가 노드 트리 돌면서 붙는 걸 이야기하는 건데 html 먼저 화면에 띄워버리는 건데 하이드레이션 도중에 유저가 뭐 하나 클릭했을 때 자바스크립트가 붙지 않았다면 아무일도 안 일어남.. 이 문제점을 이야기하는 듯)

 

하이드레이션 동안에 리액트는 걍 가만히 있다고 함

싱글 스레드니까 요청 하나 받으면 그거 수행하는 게 맞음

 

 

 

그냥 쪼개서 렌더하자

 

이렇게 하자

 

저렇게 쓰려면 그냥 suspense로 감싸기만 하면 됨 

 

=================================================