redux, redux-toolkit, react-query

 전역상태 관리 툴로 많이 사용되는 redux는 본인만의 흐름이 있어 처음에 접할 때에는 어려움이 있으나, 사실 흐름만 읽고 나면 어렵지 않다. (기본적으로 context API와 reducer를 접한 후에 redux를 공부하기를 추천한다.)

 

 redux를 이해할 때에 가장 쉽게 비유되는 것이 은행이다. 돈을 맡기고 돈에 대한 모든 과정은 은행에서 처리를 해준다. 은행에서 돈을 뽑기 위해 우리는 창구나 ATM 기기를 이용한다. redux도 이러한 흐름에서 이해해보자.

 

 먼저 우리는 관리하고 싶은 상태를 은행인 store에 맡긴다. 이 은행은 자신의 정보를 사용할 수 있는 은행서버를 갖고 있고 이 은행 서버는 곧 provider라고 생각하면 된다. 이 provider를 통해서 store가 구독을 원하는 컴포넌트에게 제공이 된다. 이 상태를 보는 것을 구독이라고 하는데 그 상태를 가져가서 구독하는 기능을 해주는 것이 useSelector이다. 그리고 이 것을 출금하고 입금하는 행위가 바로 dispatch인 것이다. 
 은행에 비유해서 이해가 잘 되지 않는다면 각각에 console.log를 찍고 그 흐름을 따라가보는 것을 추천한다.

 

 그렇다면 contex API가 아니라 이 redux로 한다면 뭐가 좋은거지? 라는 생각이 들 수 있다.

 이 것을 간단하게 설명하기 위해서 컴포넌트의 리렌더링 과정을 짧게 짚고 넘어가면 리렌더링이 된다는 것은 해당 함수를 다시 호출하는 것이고 그 함수가 호출되면 내부에 있는 참조되는 값들(객체, 배열, 함수)은 다시 생성되게 된다.(메모이제이션 작업을 하지 않는다면) 

 이렇듯 상태를 가져가서 컴포넌트 내부에서 처리하는 것이 아니라 이 상태들만 처리하는 곳이 있다면 유지보수하기에도 편하고 이러한 리소스 낭비도 없지 않을까? 그게 바로 reducer인 것이다. 상태에 대한 처리가 한 곳에서 되기 때문에 그것에 대한 에러가 있다면 그곳에서만 해결할 수 있을 것이다. 하나하나 다 찾아가면서 뒤질 필요없이..

 

 redux가 어느정도 이해가 되었다고 생각이 들때, 심기를 불편하게 하는 친구가 등장한다. 덕스 패턴이라는 친구인데 이 패턴으로 인하여 불필요한 액션함수 액션생성기 같은 보일러 플레이트 코드가 증가하게 된다. 그래서 이를 해결하기 위해 등장한 것이 redux-toolkit이다. 이런 보일러 플레이트 코드를 줄이고 async Thunk 함수를 통해 서버와의 비동기 처리 또한 손쉽게 할 수 있다. 하지만 이것도 비동기 상태관리를 위한 툴이라고 할 수 없다. 결국 비동기 처리를 하기 위해서는 Thunk 함수 내에서 로직을 개발자가 만들어서 해결해야 했기 때문에.

 여기에서 바로 비동기 상태관리 툴인 react-query가 등장한다. 비동기 처리에 대한 부분을 다 제공 해준다. isLoading을 통해 로딩일때 처리가 가능하도록 해주고 refetch라는 기능을 통해 손 쉽게 재요청을 하고 cacheTime과 staleTime을 통해 불필요하게 서버에 요청이 되지 않도록 캐시 기능 또한 제공한다. 
 그래서 나는 react-query를 접하고 나니 다른 상태관리 툴로 비동기 처리하는 것이 조금은 싫다..ㅎㅎ