처음 마주한 상태관리의 필요성
처음 상태관리에 대해 생각해봤던 경험은 멋쟁이사자들처럼 해커톤 프로젝트였다.
A - B - C 페이지에서 각각 입력을 받고, C 페이지에서 한꺼번에 백엔드로 데이터를 전달해야하는 상황이었다. 당시에는 제대로된 프로젝트 개발을 처음 해봤기에 굉장히 당혹스러웠다...
A에서 B 페이지로 넘어갈때 입력했던 정보를 props를 통해 전달해야하나? 그렇게되면 props drilling이 심해질 것 같은데 스토리지에 저장해놓아야 하는걸까? 이것보다 좋은 방법이 없을까 열심히 구글링을 해서 React Context를 알게되었다.
Context Provider 지옥 탈출기
그 후로 React Context를 애용하다가 점점 불편한 점이 늘어났다.
여러 페이지에서 관리해야하는 상태가 늘어날수록 context provider도 너무 많아지고, context 값이 바뀌면 해당 context를 구독하는 모든 컴포넌트가 리렌더링 되는 문제가 있었다.
그래서 다음으로 찾은 방법이 Zustand였다.
Recoil과 Jotai라는 상태관리 라이브러리도 있었지만, 가장 러닝커브가 적고 참고자료가 많은 Zustand를 사용하게 되었다.
처음 Zustand를 써봤을 때 솔직히 좀 당황했다.
"이게 끝이야?"
Provider로 감쌀 필요도 없고, 복잡한 보일러플레이트도 없었다. 그냥 create로 스토어 하나 만들고, 쓰고 싶은 컴포넌트에서 훅처럼 꺼내 쓰면 끝이었다.
무엇보다 상태와 로직이 한 곳에 모여있다는 게 가장 큰 신세계였다. 이전엔 상태 업데이트 함수가 어느 컴포넌트에 있는지, 어느 Context에 넘겨줬는지 파악하러 파일을 열댓 개씩 열어봤는데, 이제는 스토어 파일 하나만 보면 됐다.
하지만... 서비스 디벨롭을 하면서 새로운 문제에 마주쳤다.
Zustand의 한계
Zustand로 클라이언트 상태를 관리하는 건 정말 만족스러웠다. 하지만 문제는 서버 데이터를 다루는 데에는 한계가 있었다.
API 호출마다 isLoading, isError, data를 항상 만들어야했고, 복붙의 연속이었다...
캐싱을 적용하려 했을때는, 캐싱을 직접 구현해야해서 머리가 어지러웠다.
이러한 문제를 해결하기위해 Tanstack Query를 찾게되었다!
TanStack Query
TanStack Query는 서버 상태 관리 라이브러리다.
골치 아팠던 캐싱과 로딩/에러 처리를 알아서 해준다니
이 외에도 무한스크롤, 중복요청 방지, 데이터 최신화를 별도 구현 없이 지원해준다.
직접 짜던 코드들을 생각하면 눈물이 날 지경이다. 이걸 이제야 알다니!!!!
특히 가장 마음에 들었던 건 useQuery 하나로 이 모든 게 해결된다는 점이었다.
Zustand로 isLoading, isError, data를 매번 직접 선언하고 try-catch로 감싸던 게 단 몇 줄로 끝난다. 처음 봤을 때 Zustand 때와 똑같은 생각이 들었다.
"이게 끝이야?"
아직 본격적으로 프로젝트에 적용해보진 않았지만, 앞으로의 서버 상태 관리는 TanStack Query에게 맡겨도 되겠다는 확신이 생겼다.
다음 글은 TanStack Query를 CodIN 프로젝트에 도입한 과정과 느낀 점에 대해서 써보도록 하겠다!
