최근 ContextAPI를 억지로(?) 사용해보면서 Redux를 사용했을 때와 차이점을 확인하고 싶었다.
contextAPI?
contextAPI는 React가 기본적으로 제공해주고 있는 의존성 데이터 주입 도구이다. 엄연하게 말하자면 상태 관리 도구라는 명칭보다는 데이터 주입 도구라는 의미가 더 맞는 이유는 contextAPI의 기본적인 행동은 자식들에게 값을 전파하는 기능을 가지고 있다는 점이지, 상태를 관리하는게 주요 목적은 아니기 때문이다.
상태관리라 함은, 아래와 같은 행위를 하는 것을 말한다
1. 초기값을 설정한다
2. 초기값을 읽을 수 있다
3. 초기값을 변경할 수 있다.
예를들어, useState이란 hook을 호출하면 클로져 개념으로 상태값이 메모리에 저장되어 있고, 이 상태를 변경할 수 있는 함수를 만들어 리턴한다.
const [state, setState] = useState(0);이때 useState의 인자로 초기값을 설정할 수 있고, state을 통해 읽으며, setState을 통해 설정할 수 있으므로 상태관리 도구라고 할 수 있다.
그렇다면 contextAPI는 해당 행위가 불가능한가?
근본적으로는, 불가능하다. contextAPI가 하는 행동은 오로지 값에 대한 전파를 담당하는 것이지 상태를 관리하는 것이기 아니기 때문이다.
다만, useState와 같은 상태관리 도구와 함께 사용하여 상태관리와 관련된 값들을 자식들에게 전파하는 것이 가능하다.
위와 같이, 상태가 따로 있고 상태를 변경하기 위한 메서드를 하나의 객체로 포함하여 contextAPI의 Provider의 props로 전달하고 자식들이 이 내용을 구독하게 만들면 얼마든지 자식들은 상태를 조회하고, 변경하는 것이 가능해진다.
contextAPI를 사용하게 되면, 불필요한 prop-drilling을 막을 수 있다.
이처럼 객체지향적인 형태로 구조화하면, 상당히 redux와 유사한 형태로 보인다.
redux?
리덕스는 그 자체가 FLUX 패턴을 활용하는 상태관리 라이브러리이다. 보통 react에서 많이 쓰이기에 착각하기 쉽지만 redux는 react를 위한 라이브러리가 아니라서 어떤 프로젝트에서도 사용이 가능하다는 점이 contextAPI와의 다른점중 하나이다. (즉 상태관리 로직이 서로 동일하다면 다른 프로젝트에서 사용했던 로직을 재활용할 수 있다는 장점이 있다)
또한 react에서 주로 사용되기에 만들어진 react-redux는 contextAPI의 개념이었던 Provider을 통한 전파를 활용하여 prop-drilling을 해소한것처럼 마찬가지로 redux store의 저장소 인스턴스를 Provider을 통해 자식들에게 전파할 수 있도록 하였다. (상태를 조회하려면 메서드를 이용해야 한다)
더불어 redux는 미들웨어 기능을 제공하기 때문에 액션을 통해 상태가 변경되기 전에 미리 실행될 작업들을 정의내리기에 용이하고, store의 상태가 immutable하기 때문에 기존 상태를 기억하고 있어서 dev tools를 이용하여 상태 확인ㅇ의 프로세스를 한눈에 확인할 수 있다는 장점도 있다.
따라서 위와 같은 내용을 통해 정리하자면
- contextAPI는 정확하게 말하면 의존적 데이터 주입 툴이고 상태관리 툴이 아니다
- redux는 전역적인 상태관리가 가능한 라이브러리이고, react-redux는 이런 redux의 장점에 contextAPI를 첨가하여 구독형 상태관리를 편리하게 가능하도록 만들었다
- 더불어 Redux는 미들웨어, devtools와 같은 추가적인 도구들을 통해 개발환경을 조금 더 정교하게 만들어줄 수 있다.
그래서 결국
결론적으로, 단순하게 prop-drilling을 피하기 위해서라면 작은 단위로 contextAPI를 적용하는 것이 좋지만,
복잡하게 상태관리 로직들이 존재할 가능성이 있어 협업의 당시에 통일화된 상태 업데이트가 필요하다면 React-Redux를 사용하는 편이 낫다.
