redux-saga가 해결하고자 하는 것

saga의 특징

공식문서 발췌(https://redux-saga.js.org/)

 

1. 비동기

- redux-saga는 ES6 문법인 generator를 사용하여 비동기 flow를 더 쉽고 가독성있게 작성할 수 있도록 돕고, test도 쉽게 만들수 있다.

- 복잡한 side effect을 세부사항에 얽매이지 않고 생성할 수 있다.

 

2. 컴포지션(구성) 중심

- saga는 병렬 수행, 작업 동시성, 작업 경쟁, 작업 취소 등을 다루는 다양한 접근 방식을 가지고 코드 흐름을 완벽하게 제어한다.

 

3. 테스트하기 쉬운

- saga와 generator의 각 단계의 결과를 assertion할 수 있다.

- side effect 테스트가 빠르고 간결하고 고통스럽지않게 된다.

 

 

아래는 너무 잘 정리된 특정 블로그의 글을 정리 및 주관적인 견해를 반영한것

참고: https://min9nim.vercel.app/2020-04-23-redux-saga/

redux-saga 가 해결하는 문제

 

 

React의 등장

SPA가 대세로 떠오르면서, 컴포넌트 기반의 라이브러리들이 생겨남.

그 중에 하나가 React

React의 관심사는, 화면을 컴포넌트 단위로 구조화하여 어플리케이션의 상태를 효과적으로 렌더링하는 것에 있음.

 

하지만, 웹 어플리케이션은 화면을 렌더링하는 것 이외에 상태와 관련된 사이드 이펙트들을 잘 처리하는 작업이 필요한데,

React는 그런 것에 대해서 훌륭한 방법을 제시하지는 못함.

 

일반 상태관리에 있어서도, Prop Drilling이나 Context API으로 관리를 하면 몇가지 이슈가 있음.

 

 

Redux의 등장

기존 상태관리에서 문제가 되었던 문제를 전역상태관리로 해결하면서 등장.

action, reducer, store 라는 개념으로 전역상태관리를 수행.

 

하지만, 아직도 Redux는 action을 통해 상태를 어떻게 변화시킬 것인지에만 관심이 있음.

상태 변이를 위한 side effect에 대해서는 딱히 관심 없음.

 

아직도 상태관리의 문제는 해결했는데..

상태 변이를 위한 side effect와 같은 비즈니스 로직들은 어디에 위치하는 것이 좋을까?

 

Redux-thunk의 등장

thunk를 사용하면 async action을 트리거했을때, 그 내부에서 fetch와 같은 비동기 사이드 이펙트 로직을 수행시키고,

그 결과에 대한 상태변화 action을 트리거할 수 있다.

 

이제, 리액트 컴포넌트에서 비동기로직을 redux-thunk로 이전할 수 있게 되었다.

 

하지만 어플리케이션이 복잡해지고, redux-thunk가 비대해지는 문제가 생겼다.

async action을 한번만 발동시켰는데, 그 내부에서는 수많은 action을 dispatch하고 있는 문제가 생긴것이다.

기존 action과는 거리가 먼 함수로 점점 진화해간다.

 

action도 한번에 한가지씩.. 순수하게 만들 수는 없을까?

 

Redux-saga의 등장

saga는 generator를 이용하여 action의 순수성이 보장되도록 해준다.

saga는 특별히 비동기 처리가 필요한 액션이 발생할 때를 기다리다가 해당 액션이 dispatch되면 그에 맞는 비즈니스 로직들을 순서대로 처리해 나간다.

 

비동기 요청들도 마찬가지이다.

 

이제 action과 reducer의 로직은 간단해졌고, 모든 side effect 로직이 saga로 이동하게 되었다.

saga도 잘게 나누어서 서로 조합을 하는 등의 분리만 잘 한다면 관심사 분리가 잘 일어나게 만들 수 있다고 생각한다.