Redux toolkit thunk
리팩토링 이전에는 컴포넌트 안에서 api 호출, redux dispatch, 에러 처리등을 모두 수행하였다. 컴포넌트의 기능이 점점 복잡해짐에 따라 api 호출 뒤 동작이 매우 복잡해졌다. 또한 하나의 api로 해결이 되지 않고 여러 api를 통해 원하는 동작을 구현하는 경우도 많이 생겼다. 이럴때 마다 컴포넌트내의 비즈니스 로직 코드가 매우 길어졌다. 사실 처음 작업을 시작할때 redux 미들웨어에 대해 아는바가 없었다. 이전에 redux saga를 잠시 사용해 보았는데 사용방법이 너무 어려워서 이후에 본적이 없었다. 이후 유데미 강의에서 redux thunk를 사용하는것을 보았고 강의를 보며 사용방법을 익혔다. RTK에서 지원하는 기능이라 그런지 사용방법이 비교적 간단했다.
사용해보면서 느낀점은 컴포넌트내 비즈니스 로직이 빠지다보니 컴포넌트를 어떻게 조합하고 동작시킬것인지에 대해 집중할 수 있었다. 컴포넌트 내에서는 컴포넌트의 상태에 따라 어떤 동작을 시킬것인지만 지정해주면 되었다. 그리고 builder에 여러 상태를 등록시킬 수 있어서 로딩중이나 에러 발생시에 대한 상태정의가 편리한 부분이 있었다. 만약 해당 기능을 사용하지 않은면 컴포넌트 내에서 loading state나 error state를 따로 선언하고 state를 핸들링해주어야 했다.
그리고 thunk 파일 내에서도 dispatch가 가능한 점이 좋았다. 예를 들면, 모달창을 통해 api 호출하고 처리 완료시 모달을 닫는 동작을 기존대로 구현하려면 컴포넌트 안에서 api 호출 후 모달 state를 토클하는 액션을 dispatch 했어야 했다. 하지만 thunk를 이용하면 thunk 내에서 api 호출 완료시 모달 state를 토글하는 액션을 바로 호출할 수 있어서 컴포넌트의 코드를 더욱 간결하게 구현할 수 있었다.
그럼에도 아직 부족한 부분들이 있었다. thunk 내에서 error가 발생한 경우 특정 값을 slice에 return 하면서 reject 시키는 기능이 있다.(rejectWithValue) thunk 파일 내에서 반환시킬 값의 타입을 지정해 줄 수 있지만 기본적으로 undefined가 포함되어있다. 처음에는 그 이유를 잘 몰라서 왜그런가 했는데 평소에 사용하던 에러 타입대로 에러가 발생하는 경우에는 slice로 잘 전달하지만 예상치 못한 에러가 발생하는 경우는 thunk에서 인식(?)을 못하는것 같았다. 예를들면 코드레벨에서 발생하는 에러가 있었다. 이런 경우를 보니 왜 제작자들이 type에 undefined를 항상 넣으려 했는지 이해가 되었다. api에서 발생하는 에러 이외에도 프론트 코드에서 발생할 수 있는 에러에 대한 처리가 필요한 상태이다.
그리고 최근에 redux-persist에 대해 알게되어 활용해야할지 고민하고 있다. 이외에도 redux-persist이외에도 RTK에서 지원하는 여러 기능들이 많은것 같았다. 유용한 기능을 통해 코드를 좀 더 간결하고 보기 편하게 구현하고 싶어진다.
이번 글이 코드 리팩토링의 마지막 글이 될것 같다. 리팩토링을 한지 너무 오래되기도 했고, 이후 기능구현을 하며 또 달라진 부분들이 많기 때문이다. 짧은 시간동안 많은 기능들을 구현하기 위해 밤낮, 주말없이 몇달을 달려온 것 같다. 달라진 제품을 보며 가끔 뿌듯함을 느끼기도 하지만 아쉬움이 더 큰 것 같다. 많은 아쉬움을 채우기 위해 끊임없이 노력해야할 것 같다.
