React에서 사용하는 대표적인 상태 관리 Tool이 Redux이다. Redux는 React와 같이 개발된 것은 아니고, React가 나온 후 개발이 된 엄연한 다른 프레임워크, 라이브러리이다. 그래서 상태 관리는 무엇을 써도 상관이 없다는 것이 그 이유이다.

Redux는 Flux패턴을 사용하는 대표적인 상태 관리이다. Flux패턴을 간단히 설명하자면 단순화이다. Redux를 사용하기 위해 Reducer를 만들고 Dispatch함수를 만들기를 생각하면 이 말에 대해 이해를 할 수 없다. 하지만 Flux패턴은 MVC 패턴을 깔끔하게 사용하기 위한 패턴이다.

MVC에서 Flux 패턴으로

대표적인 MVC 패턴으로 소개되는 언어가 하나 있는데 바로 JAVA이다. 자체적으로 주변에서도 JAVA는 MVC패턴이라는 것을 다 알고 있다. 그래서 그 장점을 가지고 JAVA를 영업한다.

그런데 MVC는 단점이 있다.

위 이미지처럼 하나의 Controler가 여러 모델을 관리하고 View는 Model들을 가지고 그린다. 깊이가 깊지만 않으면 견딜 수 있는 모델이지만 React에서 Component의 깊이가 얕은 경우를 본적이 있는가? 단순한 ToDo만들기가 프로젝트면 크게 문제가 되지는 않을 것이다.

위 이미지는 플럭스 패턴이다. Action으로 Dispatch가 일어나며 그때만 Store가 수정된다. 그 수정된 정보는 View로 바로 적용이 된다.

그림이 너무 극과 극을 달리는 것 같지만 실제 서비스를 구현하게 되면 위 그림과 같이 구성이 된다.

Container의 활용

순수하게 Flux패턴은 간단하다. 하지만 그것을 적용하여 만들어진 Redux는 간단하지 않다. 위에서 언급한 것처럼 뭐 뭐 계속 구성을 하고 만들어야 사용이 가능하다.

사용하는 방법은 또 쉬운가? Component에 접목하여 사용하려면 Provider로 감싸고, 사용하는 Compoent에 connect HOC를 감싸야 한다. 이러니 다들 안쓰고 말지 한다.

그래서 나온 개념이 Container이다. 기본적인 상태 관리가 지향하는 방향과는 조금 다르지만 React로 개발하는 개발자들에게는 매우 좋은 기능이었다.

단순히 이미지만 보자. Redux를 사용하면 Store에서 관리되는 데이터들이 각각의 Component에 값들을 뿌려준다. Compoent는 다시 값을 Store로 던진다.

위 MVC패턴과 Flux패턴 중 Flux에 가까운 모습이다. 그리고 Compoent의 구성은 MVC에 가까운 구성이다. 그림으로만 보면 두가지 패턴을 모두 사용하면서 편한 부분만 사용할 수 있다고 알게 된다.

하지만 다시 얘기하지만 우리의 친한 친구 Redux는 친절하지 못하다. Component에서 값을 요구하기 위해 치루어야 하는 준비가 너무 크다. 그것을 보안한 것이 Container이다.

이게 Container로 관리하는 React + Redux 프로젝트의 패턴이다. 그림만 보면 위에서 손가락이 아프게 설명한 Flux패턴은 보이지도 않는다. 그리고 관리하기 힘들다는 MVC의 패턴만 보인다. 그러면 Flux는 어디 있는가?

자세히 보면 Redux와 연결된 Container가 있다. 한번 더 설명하지만 Redux는 Flux패턴이다. 다시 말해 Redux와 Container연결 부분까지 해당 패턴이 사용된다. 그리고 다른 Component들은 Container로 받은 값들을 props로 내려서 사용한다.

React라서 가능한 경우이다. 값을 아래에서 위로 올리는 것은 MVC에서 쉬운 일이 아니다. 값은 위에 아래로 내려가는 것이 기본이다. 그렇기에 값들을 관리하는 것을 Store. 즉, Redux로 관리하고 그 값들은 해당 값을 필요로 하는 Component의 묶음, Container가 받는다. 그리고 묶여있는 Component에 내려 주는 것이다.

Hook!s

위에서 한번 언급한 것처럼 Container는 상태 관리가 추구하는 방법과는 다르다. React나 패턴들의 문제가 아닌 Redux의 사용법이 복잡하기 때문이었다. 하지만 이번에 Hooks가 업데이트 되면서 위의 문제점이 사라졌다.

지금까지 connect HOC로 Compoent를 감싸야 했는데 이제 그 부분을 Hooks 중 하나인 useDispatch로 대체할 수 있게 되었다.

그러면 다시 정리 해보면 다음과 같은 결론이 나온다.

1. Redux의 사용법이 편해졌다.
2. 이제 어떤 Component든 직접 Store에서 값을 가져오고 바꿀 수 있다.

그러면 Container가 필요 없다는 결론이 나온다.

이제 이 그림처럼 사용이 가능하게 된 것이다.

정리(...할 것은 없지만)

Hooks를 사용하면 Container는 제거하자.

실제로 이런 효과를 얻으려고 Mobx를 사용하는 경우가 많았다. Component라는 개념을 Container와 Component로 나누는 것이 맞지 않다.

필요하지 않다고 꼭 제거해야 하나?라는 질문에는 이렇게 답한다. 관리 포인트 줄여야 산다...