Do we need Redux? (Part 2)
Part 1에서는 Flux에서 Redux로 갈 때의 장점이 무엇인지, 어떤 방식으로 동작하기에 그런 장점을 얻는지에 대해 알아보았다. 이번 글은 Flux의 구조를 유지하면서도 큰 변화 없이 Redux의 장점-주로 테스트 가능성-을 얻어오기 위한 코드의 변화에 대해 서술하려고 한다.
좋다. 현재 코드의 기능을 건드리지 않으면서, 코드 구조만 조금씩 건드리는 방식으로 리덕스의 함수형 구조로 적당히 옮겨가 그 장점 중 일부를 얻어낼 수 있을 것 같다.
- Part 1 마무리 부분
아차, 이제 전/후 코드를 비교할텐데, 그 사이에 뜯어고친게 한둘이 아니라 직전/직후 코드를 가져오는 데에 어려움이 있었다. 바뀐 변수명이나 데이터 구조는 잠시 넘어가주시고, Container, Store, Actions가 어떻게 연결되었는지에 더 관심을 가지고 살펴봐주시면 감사하겠다.
Store
변경 후, 여전히 flux-utils의 Dispatcher와 ReduceStore를 사용하고 있지만, 그 내부의 로직이 단순하게 밖으로 옮겨졌다. 만약 지금의 코드를 Redux 기반으로 옮겨가려고 한다면 마지막 몇 줄만 고치면 될 정도이다.
한편, reducer가 분리되어 reducer를 테스트할 수 있게 되었다. 기존 코드에서는 스토어 로직을 테스트하려면 Action을 만들고 Dispatcher에 태워 스토어가 어떻게 변경되었는지 확인했어야 했다면, 이젠 리듀서만 테스트하면 된다.
이제서야 Dan Abramov 아저씨가 2015년 Redux에 대해 발표했던 이 영상과 비슷한 형태를 갖춰가기 시작했다.
Container
Container 테스트의 가장 큰 걸림돌이었던 getStores와 calculateState 함수를 컨테이너 바깥으로 걷어냈다. 덕분에 스토어에 연결되지 않은 컨테이너 컴포넌트만을 테스트 시에 뽑아, 테스트를 진행할 수 있게 되었다. 동작할 땐 컨테이너이지만, 테스트할 때엔 Presentational component가 되는 셈이다.
여기에서 중요한 부분은 스토어와 액션의 의존성을 제거한 inject함수인데, 형태를 만들어내는 데에 React-redux의 아이디어를 많이 참고했다. 이 코드를 보자.
이 코드는 결국 Flux 위에서 react-redux를 흉내내기 위한 코드로, 결국 Flux Container 코드에 기반하고 있다. 만약 Redux로 완전히 넘어가게 된다면, 이 함수 대신 react-redux의 connect함수로 갈아탈 수 있을 것이다.
Actions
Ajax와 dispatch를 분리해서 구현하겠다는 생각으로 API와 Actions를 구분했다. async/await의 도움으로 코드가 더 깔끔해지기도 했다. redux-saga의 방식처럼 await/async를 generator/yield 패턴으로 바꾸고 나면 액션 자체도 더 편하게 테스트를 할 수 있을 거라고 알고 있지만, 아직 코드 내에 generator를 사용한 부분이 없어 쉽게 도입하지는 못하고 있다. 어쩌면 다른 코드가 전부 Redux 베이스로 변경된 이후에 Saga를 도입하는 것이 더 빠를 수 있겠다는 생각도 든다.
마무리
코드가 많고 정작 별 내용은 없지만, 아직도 나처럼 flux를 사용하고 있는 사람이나 팀이 있다면(없겠지만) 좋은 참고가 될 수 있을 거라고 생각한다.
