10. 사용 사례 시나리오 4: React Tracked

React Tracked 이해하기 (useState, useReducer, React Redux와 함께 사용하기)

🔖 1. React Tracked란?

특정 값만을 변경했는데 새로운 컨텍스트 값이 전파되고, useContext는 리렌더링을 감지한다. 따라서 불필요한 리렌더링이 발생할 수 있다.
React Tracked를 사용하면 useContext 대신 사용할 수 있는 useTracked 훅을 정의한다. 이는 상태를 proxy로 감싸고 사용을 추적한다.

const useFirstName = () => {
  const [{ firstName }] = useTracked();
  return firstName;
};

위에서 언급했듯이 Proxy 기반으로 추적한다. useTracked은 상태 객체를 Proxy로 감싸거나, 그와 유사한 기법을 사용하여 속성(get) 접근을 가로챈다. (비슷한 내용이 9장: valtio 때도 나왔다) 그 결과, 컴포넌트가 해당 상태 객체의 어떤 속성을 실제로 읽었는지(접근했는지)를 기록할 수 있다.
접근된 속성만 리렌더링을 트리거 한다. 렌더링이 끝나면 useTracked은 "이 컴포넌트는 A, B, C 속성에 의존하고 있네" 라고 인지하고 해당 속성들만 추적한다. 이후 A, B, C 중 하나라도 값이 변하면 해당 훅을 사용하는 컴포넌트를 리렌더링한다. 반면, 사용하지 않은 속성은 바뀌어도 이 컴포넌트를 다시 그리지 않는다. (아주 효율적이야)
리렌더링 최적화를 한다. 전역 상태나 큰 객체에서 정말로 필요한 필드만 “실제 의존”으로 간주하기 때문에, 불필요한 렌더를 크게 줄일 수 있다. 예를 들어 user.name만 접근했다면 user.age나 user.email이 변해도 컴포넌트가 재렌더링되지 않는다.

각 렌더링 과정에서 어떤 속성을 읽었는지 기록하고, Proxy를 통해 속성 접근을 감지하는 과정에서 성능 overhead가 발생할 수 있을 것 같다. 일반적인 상황에서는 큰 문제가 안 되겠지만, 복잡한 데이터 구조나 빈번한 렌더링이 있는 경우 주의하면 좋겠다.
상태가 깊게 중첩된 구조일수록 추적 로직이 많아지기 마련이다. 예를 들어, obj.a.b.c처럼 깊숙이 들어가는 속성까지 추적해야 하는 경우, 생각치 못한 성능 비용이나 예상치 못한 재렌더링이 발생할 수 있을듯 하다. (하지만 이는 비단 useTracked의 단점만은 아닌 것 같다)
평소 Redux 같이 명시적 액션/리듀서 구조에 익숙한 팀이라 useTracked가 제공하는 자동 추적은 추상적이라고 느낄 수 있을듯 하다. 상태 변경 흐름이 명확하게 보이지 않기에 상태 추적 / 디버깅이 어려울 수도 있겠다.

Last updated 6 days ago