TOAST UI

큰 규모의 프론트엔드 개발을 하다 보면, 사용자의 로그인 정보나 특정 UI의 메타데이터 혹은 서비스의 데이터 등 애플리케이션의 상태를 저장하고 관리할 전역 스토어가 필요할 것이다. 그리고 이런 전역 스토어를 직접 개발할 것인지도 결정해야 할 것이다. 이 포스트에서는 여러 상태 관리 도구 중, Apollo의 로컬 캐시, Recoil, Redux 3가지만 다룰 예정이다. 그리고 각 도구는 개요, 코드 설명, 후기 3가지로 나눠서 다룰 예정이다.

Redux Saga는 테스트가 쉽기로 유명하다. 하지만, 더 간단해질 수 있다면 어떨까? Jeremy Fairbank는 더 간단한 테스트를 위해 redux-saga-test-plan을 디자인했다.

이번 글에서는 Redux-Saga의 Channel(이하 채널)에 대해 정리해보고자 한다. 채널은 Redux-Saga의 초기 버전에서부터 고려했던 API는 아니다. 그런데 Stackoverflow에서 외부 이벤트를 Saga와 어떻게 연결하냐는 질문에서 채널의 필요성이 표면적으로 나타나기 시작했다. 핵심은 Push 기반과 Pull 기반 동작이다.

지난 글에서 Redux-Saga와 사이드 이펙트를 가지고 공부 겸 정리 겸 글을 작성했다. 이번 글에선 Redux-Saga에서 사용하는 제너레이터함수, 이펙트에 대해 정리해보려 한다. 제너레이터함수는 협력적이고,run-to-completion이 아니며, 그렇다고 비동기도 아닌 그런 함수다. 그리고 이펙트는 Redux-Saga의 가장 중심이 되는 특징이다. 마치 Redux의 Action처럼 단순한, 일반적인 객체인데 개발자에겐 어마어마한 마법을 보여준다. 그리고 대부분의 서비스 로직을 이 이펙트로 작성한다. 이 두 가지를 이해한다면 이제 Redux-Saga는 뭔지 모르겠는데 엄청 대단해 보이는 것에서 엄청 대단한 건데 난 이해함ㅋ이 될거라 생각한다.

지난 1년 6개월 동안 리액트, 리덕스를 공부하고 활용해 웹 애플리케이션을 개발했다. 지금도 개발하고 있고, 여전히 비동기 처리와 같은 사이드 이펙트(Side effects)를 고민하고 있다. 리액트, 리덕스는 함수의 응용, 순수 함수, 불변성 등 함수형 프로그래밍을 지향한다. 그리고 사이드 이펙트를 원하지 않는다. 하지만 세상일은 뜻대로 되지 않는다는 말을 증명하듯 서비스는 사이드 이펙트 없이 개발할 수 없었다. 사실 처음에는 사이드 이펙트라는 개념도 몰랐다. 그냥 무언가 개발에 어려운 점이 있는데, 그 무언가가 무엇인지 표현도 못 했다.

React(이하 리액트), Redux(이하 리덕스) 생태계에서 소켓과 같은 외부 이벤트 처리는 개발에 많은 고민을 안겨준다. 똑같은 외부 이벤트가 발생하더라도 앱의 상태에 따라 다르게 처리하고 싶을 수도 있고, 무시하고 싶을 수도 있으며, 앱의 상태와 관계없이 항상 처리하고 싶을 수도 있다. 특히 외부 이벤트가 리덕스의 액션과 연결되는 경우 리덕스의 미들웨어를 통해 액션이 Dispatch 됐다는 것을 알아야 한다. 때문에 단순한 리덕스 스토어의 API만으로는 모든 서비스 로직을 처리하기가 상당히 까다롭다.

Redux는 Event Sourcing패턴과 Functional programming을 결합하여 라이브러리 형태로 구현한 컨테이너다. 이 컨테이너는 애플리케이션의 상태를 저장하고, 쉽게 예측할 수 있도록 하여 일관된 구현을 유지할 수 있도록 하고, 테스트, 유지보수, 디버깅 등을 손쉽게 처리할 수 있도록 한다.