올해 상반기 진행했던 세 번의 팀 프로젝트 모두 Redux와 React Redux를 사용했다. 여러 페이지에서 사용하는 상태들이 있었기 때문이다. 한 군데서 그 상태들을 관리하고 싶었다.
첫 프로젝트에 Redux를 도입한 이유는 명확했다.
어떠한 문제점이 발생했을 때 해결이 용이하도록 생태계가 큰 라이브러리를 사용하는 것이 맞다고 생각했고, 프로젝트 규모가 짐작이 가지 않았을 때라 큰 프로젝트에는 단순히 Context Api보다 Redux를 사용하는 편이 관리에 더 낫다는 의견도 접했기 때문이다. 다른 라이브러리를 접해보지 않았으니 작성해야할 보일러 플레이트가 굉장히 많다고 느껴지지도 않았다.
두, 세번째 프로젝트에서는 경험해봤던 라이브러리를 사용하는 것이 더 효율적이라고 판단해 팀원들과 큰 고민 없이 Redux를 그대로 사용했다. (물론 지금의 나라면 Recoil과 Context Api를 적절히... 사용해보자고 주장할 것이다😉)
프로젝트가 끝나고 상태관리에 대해 공부하면서 Redux와 React Context는 다른 목적을 가지고 있다는 글을 보게 되었다.
원문 부분번역
다음에 개발을 할 때는 정확히 알고 적절한 방법을 선택할 수 있도록 공부해보자!
Redux가 무엇인가요?
Redux는 "actions"라고 불리는 이벤트를 이용해 application의 상태를 관리하고 업데이트하는 패턴이자 라이브러리이다.
Redux는 상태를 관리해준다
React Context는 무엇인가요?
context를 이용하면 단계마다 일일이 props를 넘겨주지 않고도 컴포넌트 트리 전체에 데이터를 제공할 수 있습니다
context의 주된 용도는 다양한 레벨에 네스팅된 많은 컴포넌트에게 데이터를 전달하는 것입니다
라고 공식문서에서 이야기하고 있다.
즉 Context는 상태관리가 아닌 Props drilling을 피하는데 그 목적을 두고 있다.
상태관리란?
상태관리란 시간이 흐름에 따라 상태가 변화하는 방식
- 초기 값을 저장한다
- 현재 값을 읽는다
- 값을 업데이트 한다
useState와 useReducer 는 상태관리의 좋은 예이다.
그와 비슷하게 Redux와 MobX 또한 명확히 상태관리 라고 할 수 있다.
React-Query, SWR, Apollo 및 Urql 과 같은 서버 캐싱 도구들도 가져온 데이터를 기반으로 초기 값을 설정하고, hook을 통해 현재 값을 반환하며, ‘서버 변화'를 통한 업데이트가 가능하고, 컴포넌를 re-rendering 하는 것을 통해 변화를 알 수 있기 때문에 상태관리 라고 정의할 수 있다.
Context + useReducer은 언제 사용하나요?
application의 특정 부분에서 그렇게 복잡하지 않은 리액트 컴포넌트의 상태 관리가 필요할 때
Context의 특성 및 역할
- 어떠한 것도 저장하거나 관리하지 않는다
- React 컴포넌트 내부에서만 동작한다
- 하나의 값을 내려보낸다 (그 값은 어떠한 것이라도 가능)
- 그 하나의 값을 읽는 것이 가능하다
- props-drilling을 피하기 위해 사용할 수 있다
- React DevTools에서 Provider, Consumer 컴포넌트에 제공하는 현재 context value를 보여주지만, 시간이 흐름에 따라 어떻게 value가 바뀌었는지는 보여주지 않는다
- context value가 바뀔 때 consuming 컴포넌트들을 업데이트 한다, 하지만 업데이트를 스킵할 수 있는 방법은 없다
- 부수효과에 대한 어떠한 메커니즘도 포함하지 않는다
Redux는 언제 사용하나요?
Redux는 아래와 같은 경우 유용하다
- app의 여러 부분에서 많은 양의 application 상태가 필요할 때 (다른 UI 레이어끼리 상태 관리 로직을 공유하고 싶을 때)
- 상태가 자주 업데이트 될 때
- 그리고 그 상태를 업데이트 하는 로직이 복잡할 때
- UI 레이어로부터 상태관리 로직을 분리해서 작성하고 싶을 때
- 시간의 흐름에 따라 상태가 어떻게 변화하는지 추적하고 싶을 때 (디버깅에 용이)
- app이 중간 ~ 큰 규모의 코드베이스로 이루어져 있을 때, 그리고 그것을 많은 사람들이 작업할 때
- application에 있는 상태가 언제, 왜, 어떻게 업데이트 되는지 이해하고 싶을 때와 시간이 흐름에 따라 상태의 변화를 시각화 하고 싶을 때
- 부수효과, 지속성(persistence), 데이터 직렬화(data serialization)에 있어 더 강력한 능력이 필요할 때
- Redux middleware를 사용해 action이 dispatch 된 경우 부가 로직을 추가하고 싶을 때
React-Redux?
React-Redux 라이브러리는 Redux 에서 상태 값을 읽고 action 을 React 컴포넌트에게 전달하여 Redux 저장소와 상호 작용 할 수 있도록 도와주는 UI 바인딩 레이어
결론
💡 원문 저자의 추천
- 단순히 props-drilling을 피하고 싶은 것이면
Context - 그렇게 복잡하지 않은 리액트 컴포넌트의 상태를 다루거나, 외부 라이브러리를 사용하고 싶지 않은 경우에는
Context+useReducer - 시간이 지남에 따라 변경되는 상태에 대한 더 나은 추적성이 필요한 경우, 상태가 변화할 때 특정 컴포넌트만 re-render 되었으면 하는 경우, 부수효과 관리에 대한 더 강력한 능력이 필요한 경우, 또는 이런 비슷한 문제의 경우에는
Redux + React Redux
💭 나의 프로젝트 돌아보기
프로젝트 이후에 recoil을 짧게 사용해봤는데 'Redux에서 작성한 보일러 플레이트가 꽤 많았구나' 라고 느꼈다.
Continew에서 계약서 폼을 작성할 때 Redux를 이용해 내부 상태를 관리했었는데 돌이켜보니 이 부분은 상태의 양이 많긴 했지만 가장 큰 목적은 props-drilling을 피하기 위해 Redux를 사용했었다. 그래서 Context + useReducer를 사용했어도 괜찮았을까...? 라고 생각해봤지만 컴포넌트가 복잡한 구조이고 많이 나누어져 있어서 re-rendering을 생각하면 Redux를 선택했던 것도 나쁘지 않았던 것 같다.
Perfumism에서는 향수 filtering 할 때의 향조 상태 관리는 하위 컴포넌트가 무조건 re-rendering 되어야하고 복잡하지 않은 구조라 Context + useReducer를 써도 괜찮았겠다고 생각한다. 다만 Redux를 사용해서 코드가 좀 깔끔해보이는 면은 있다고 느꼈다.
참고자료
https://ko.redux.js.org/
https://ko.reactjs.org/docs/context.html
https://blog.isquaredsoftware.com/2021/01/context-redux-differences/
https://olaf-go.medium.com/context-api-vs-redux-e8a53df99b8
