[ 모던 리액트 : Deep Dive ] - 리액트에 대해

 

📍 들어가기

인턴으로 입사한지 어느덧 2달이 지났다.

 

개발에 대해 무엇을 배웠는가...?

실력은 얼마나 성장했는가...?

 

대한 물음에 답을 하자면, 스스로에게 아쉬운 마음이 들었다.

단순한 기능 구현이 아닌, 원리와 체계를 갖춘 코드로 만들어내고 싶었기 때문이다.

 

이 책이 출간되자마자 설레는 마음을 감출 수 없었다.

꼼꼼하게 챕터들을 살펴보며, 리액트에 대한 지식의 구멍들을 막아보려고 한다.

---

✅ 리액트에서의 렌더링

여기서 말하고 있는 렌더링은 브라우저의 렌더링과의 개념과는 다르다.

 

리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이
현재 자신들이 가지고 있는 props와 state의 값을 기반으로
어떻게 UI를 구성하고, 어떤 DOM 결과를
브라우저에 제공할 것인지 계산하는 과정

1. 최초 렌더링
2. 리렌더링 👉 최초 렌더링 이후 발생하는 모든 렌더링을 의미
   • class component
     • setState
     • forceUpdate 👉 강제 리렌더링을 감지해 shouldCompoentUpdate는 무시
   • function component
     • useState의 setter
     • useReducer의 dispatch
     • key props 👉 current 트리와 workInProgress 트리 사이에서 같은 컴포넌트인지를 구별하는 값
       만약, 이게 없다면 단순히 파이버 내부의 sibling 인덱스만을 기준으로 판단.

렌더링 프로세스가 시작되면 

컴포넌트의 루트에서부터 아래쪽으로 내려가면서 업데이트가 필요하다고 지정된 컴포넌트를 찾게 된다.

 

클래스형의 경우에는 render( )를, 함수형의 경우에는 FunctionComponent( )를 호출한 후, 그 결과를 저장하는 것이다.

 

사실 리액트에서의 렌더링 단계는 2단계이다.

 

📍 Render Phase (렌더 단계)

컴포넌트를 render( ) / return 한 결과와 이전 가상 DOM을 비교해 변경이 필요한 컴포넌트를 검사하는 단계이다.

• type
• props
• key

위 3가지 중 하나라도 변경된 것이 있으면 변경이 필요한 컴포넌트로 체크한다.

📍 Commit Phase (커밋 단계)

그 다음으로 실행되는 것이 바로 커밋 단계이다.

렌더 단계의 변경 사항을 실제 DOM에 적용하여 사용자에게 보여주는 과정이다.

 

즉, 리액트가 먼저 DOM을 커밋 단계에서 업데이트한다면, 여기서 만들어진 모든 DOM 노드와 인스턴스를 가리키도록 리액트 내부 참조를 업데이트 한다.

이후, 클래스형의 경우 componentDidMount, componentDidUpdate를, 함수형의 경우 useLayoutEffect 훅을 호출한다.

 

❗️여기서 ❗️
리액트의 렌더링이 일어난다고 해서 반드시 DOM 업데이트가 일어나는 것은 아니다.

 

렌더의 과정은 거쳤지만 변경사항이 없다면 커밋 단계를 거치지 않는다.

이를 통해 리액트의 렌더링은 꼭 가시적인 변경이 일어나지 않아도 발생할 수 있다는 것을 알게 되었다.

 

렌더링은 항상 동기식으로 작동하기에 렌더링 시간이 길어지면 길어질수록 성능 저하를 야기하고
브라우저의 다른 작업까지도 지연시킬 가능성을 높인다.

 

다만, 의도적으로 가벼운 컴포넌트를 먼저 렌더링하도록 비동기 렌더링 작업을 수행할 수 있다.

특정 렌더링의 우선순위를 낯추거나, 중단하거나 재시작, 포기까지 가능하다.

---

✅ Memoization

useMemo, useCallback 훅과 고차 컴포넌트인 memo는 리액트에서 발생하는 렌더링을 최소화하기 위해 제공되고 있따.

 

나 역시도 그랬지만, 이러한 최적화 기법을 언제. 어디서. 어떻게 정확하게 사용하는지에 대해서는 확실하게 답변할 수 없었다.

이 책에서는 2가지 주장을 제시하고 있다.

 

1️⃣ 섣부른 최적화는 독이다. 꼭 필요한 곳에서만 memoization을 사용하자.

섣부른 최적화를 가리키는 말로 premature optimization , premature memoization 이라는 용어가 존재하듯이 상황에 따라 memoization의 비용이 달라지기에 경계해야 한다고 말하고 있다.

 

만약, memo의 작업이 반드시 최적화에 도움이 되었었다면 개발자에게 선택권을 주지 않았을 것이다. 

렌더링도 비용이지만, 메모 자체도 비용이라는 것을 잊지 말아야 한다. 

 

리액트 공식문서에는 아래와 같은 내용이 나와있다.

useMemo는 성능 최적화를 위해 사용할 수는 있지만, 의미상으로 그것이보장된다고 생각하지는 마세요.
가까운 미래에 React에서는, 이전 메모이제이션된 값들의 일부를 “잊어버리고” 다음 렌더링 시에 그것들을 재계산하는 방향을 택할지도 모르겠습니다.
예를 들면, 오프스크린 컴포넌트의 메모리를 해제하는 등이 있을 수 있습니다.
useMemo 를 사용하지 않고도 동작할 수 있도록 코드를 작성하고 그것을 추가하여 성능을 최적화하세요.

 

따라서 우리는 렌더링이 자주 일어나는 곳을 예측해서 memo를 사용하는 것이 아닌,

애플리케이션을 개발한 이후에 useEffect나 개발자 도구로 어디서 얼마나 렌더링이 일어나고 있는지 분석하여 적용하는 것이 올바르다. 

 

2️⃣ 렌더링 과정 비용은 비싸다. 모조리 memoization을 사용하자.

 

1번과 2번의 주장의 공통 전제는 일부 컴포넌트에서는 memoization을 하는 것이 성능에 도움이 된다는 것이다. 

그래서 우리에게 주어진 선택권은 2가지인 것이다.

 

일부에만 적용하기 vs 모두 다 적용하기

 

memo가 이점이 있는 것은 맞지만, 잘못 적용하면 어떻게 될까?

• props에 대한 얕은 비교 발생

물론 해당 상황이 얼마나 큰 영향을 줄까? 에 대해 언급한다면,

props가 크고 복잡해진다면 당연히 1개의 비용이라도 거대해 질 수 밖에 없다.

 

반면, memo를 하지 않는다면 어떻게 될까?

• 렌더링으로 발생하는 비용
• 컴포넌트 내부의 복잡한 로직의 재실행
• 위의 두 가지 상황이 모든 자식 컴포넌트에서 반복해서 발생
• old 🆚 new tree 의 비교

해당 상황들이 발생하게 된다.

 

그래서 리렌더링이 발생할 때, memoization과 같은 별도의 조치가 이루어지지 않는다면 객체는 새로 생성되고 참조값은 달라지게 된다.

 

❗️여기서, 변화된 참조 값이 의존성 배열에 들어가 있다면..?  ❗️

값 자체는 똑같으나 참조 값이 달라지므로 불필요한 리렌더링이 발생하게 되는 것이다.

 

---

🌈 정리하기

리액트에서의 렌더링, 그리고 리렌더링에서 성능을 최적화 할 때 우리가 생각해봐야 할 부분들.

렌더 단계와 커밋 단계를 살펴보면서 렌더링과 DOM의 관계를 정확하게 살펴보았다.

 

개발을 진행하며, 수시로 컴포넌트의 렌더링 상태들을 분석하는 과정.

이를 통해 memoization이 필요한 곳이 어디인지 실무에서 스스로 찾아가는 능력을 길러내는 것이 필요해보인다. 

---

📚 참고자료

• 리액트 공식문서
• 모던 리액트 : Deep Dive