코드숨 리액트 6기 4주차 회고
4주차 수업의 주제는 바로 Redux입니다. React에서 선언형 프로그래밍을 하기 위해 사용하는 ‘상태관리’라는 개념 중에서도 특히 전역상태를 효과적으로 관리하기 위해서 사용하는 라이브러리입니다.
마침 최근에 서비스의 규모가 커지고 복잡도가 올라가면 어떤 방식으로 상태를 관리하는것이 가장 좋을까에 대한 고민을 하고 있던 차에 많이 배우고 고민해볼 수 있었던 시간이었습니다:)
함께 배운 Flux 패턴은 View에서 일어나는 Action을 dispatcher를 통해서 reducer로 가공된 새로운 상태를 store에 전달하고, View에서는 다시 이 업데이트 된 store값을 기반으로 새로운 View를 rendering해줍니다.
또 React Component들은 렌더링만을 담당하는 Presenter와 이 Presenter에 필요한 상태 및 함수를 전달하는 Container로 분리합니다.
데이터를 단방향으로 관리하고, 각 함수들과 컴포넌트는 분리된 하나의 역할만을 담당함으로써 서비스의 복잡도 낮아지고 유지보수가 용이한 구조로 서비스 설계가 가능해질 것 같다는 생각이 들었습니다.
과제를 수행할때는 이런 redux앱을 TDD로 구현하면서 dispatch와 selector를 mocking하여 Container 컴포넌트를 테스트 해보고, reducer에 대한 테스트 코드를 작성하면서 redux의 테스트 코드 작성에 대한 연습이 된 것 같습니다:)
사실 개인적으로는 react 앱을 개발 할 때 정말 전역으로 관리를 해야 하는 상태를 제외하고는 가급적 redux 사용을 지양하는 편입니다.
그 이유는
- 전역 상태를 과하게 사용하는 것은 전역 변수와 비슷하게 네임스페이스를 오염시킬 위험이 있다.
- 특정 컴포넌트에서만 제한적으로 사용되는 상태를 전역 상태로서 관리하는 것은 의미론적으로도 맞지 않다(해당 전역 상태가 어느 컴포넌트들에서 상호작용되는지 추적이 어렵다).
라고 생각하기 때문입니다. 이 때문에 상태를 관리할 때는 해당 상태를 사용하는 컴포넌트와 최대한 가까운 곳에 선언하고, 그럼에도 불구하고 props로 전달해줘야 하는 깊이가 너무 깊어지는 prop drilling이 발생하면 context API나 recoil, mobx등의 해결책을 사용해왔습니다.
이번주 수업에서 배운 지식으로 redux뿐만 아니라 위에 언급된 상태관리 솔루션에 대한 테스트코드 작성에 대한 힌트도 많이 얻은것 같아서 함께 연습해보는것도 좋겠다는 생각이 들었습니다:)