prop drilling
props를 오로지 하위 컴포넌트로 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 React Component 트리의 한 부분에서 다른 부분으로 데이터를 전달하는 과정
장점
컴포넌트 간에 데이터를 전달하는 가장 쉽고 빠르게 전달 할 수 있다.
컴포넌트를 잘게 분할해서 props drilling을 통해 전달하면, 코드를 실행하지 않고 정적으로 따라가는 것만으로도 어떤 데이터가 어디서 사용되는지 쉽게 파악할 수 있으며, 수정도 용이하다. (작은 규모의 어플리케이션에서)
prop 전달이 10개, 15개 같이 더 많은 과정을 거치게 된다면 어떻게 될까?
코드를 읽을 때 해당 prop을 추적하기 힘들어지고 유지보수도 더욱 어려워진다.
단점
- 필요보다 많은 props를 전달하다가, 컴포넌트를 분리하는 과정에서 필요하지 않은 props가 계속 남거나 전달되는 문제.
- props 전달이 누락되었는데 defaultProps가 과용되었을 때, props가 전달되지 않은 상황을 인지하기가 어려운 문제.
- props의 이름이 전달중에 변경되어서 데이터를 추적하기가 쉽지 않게되는 문제.
해결방법
- 전역상태관리 라이브러리 활용한다.
(Redux, context API, MobX ...)
2.컴포넌트를 여러 구성 요소로 나눈다.
Context API
리액트 hooks가 나오면서 비대한 Redux대신 Context를 활용해서 개발하는 게 권장 되고 있다. Context는 수단일 뿐 사실상 상태관리 자체는 리액트 컴포넌트의 useState와 useReducer 로 하게 된다. 역할에 맞게 여러 Provider를 쪼개서 관리 할 수 있고 또 관련된 컴포넌트 들의 상위에 Provider를 감싸면 되기 때문에 전역 상태가 최상단에 위치하는 Redux보다 가까이서 상태를 관리 할 수 있게된다.
하지만 Context도 문제가 있다. Redux는 의존해서 사용하는 값이 변할때 리렌더링이 되도록 최적화 되어있지만 Context의 경우 해당 값 말고 다른 값이 변경될때도 컴포넌트는 재호출 되어서 리렌더링이 발생한다. Context를 다룰때에는 꼭 관심사에 따라 모두 다 분리해서 관리 해야한다. 하지만 어플리케이션이 비대화 될수록 관심사가 많아지면 관리하기 어려울정도로 래핑이 많아지는 문제가 있다. 중첩되는 컴포넌트들이 많아지니 성능 이슈도 생긴다.
