오늘은 개인 과제와는 별개로 진행 중인 상태관리 라이브러리 제작에 대해 이야기 해보려 합니다.
만들기 전
상태 관리 라이브러리 제작에서는 zustand 전역 상태를 활용한 서버 상태 동기화 미들웨어를 제작 중 입니다.
제작 동기는 이렇습니다.
전역 상태 관리 도구인 zustand의 간단한 보일러 플레이트와 강력한 상태 관리에 매력을 느껴 어떠한 단점이 있을까? 내부적으로 어떻게 작동하고 있을까? 등 파헤쳐 보던 도중 zustand는 생각보다 미완성적인 상태관리 라이브러리이고, 미들웨어로 보완을 하고 있는 현재 개발 진행중인 상태관리임을 알게 되었습니다.
그래서 현재 있는 전역상태 캐싱 미들웨어 & 리렌더링 최적화 셀렉터 등 이러한 기능 말고 zustand에서 처리하기 힘든 복잡한 비동기 관리, 즉 서버 상태를 미들웨어를 통해 관리하면 TanstackQuery와 함께 사용하여 생기는 보일러 플레이트 증가, 캐시 중복 관리, 서버 상태 관리 고급 기능의 수동화 등 단점을 보완할 수 있을 것 같다고 생각하였습니다.
그리하여, zustand 내부에서 복잡한 비동기를 간편하게 관리하는 미들웨어를 만들어보고 싶었습니다.
진행도
그리하여 제작을 시작하였고 처음엔 관련 zustand 내부 로직을 파헤치고, zustand의 미들웨어들을 파보았습니다.
zustand 내부 로직을 보며 어떠한 점으로 인해 복잡한 비동기 처리가 어려워 서버 상태를 나누었는지 파악하였고,
미들웨어들을 파보며 어떠한 방식으로 zustand의 간단한 보일러 플레이트를 크게 헤치지 않고 기능을 추가하였는지 파악 하였습니다.
그런 후 1차적인 목표로 key값을 사용해 중복 fetch를 하지 않는것을 목표로 잡았습니다.
함수의 인자로 key값, fetch함수, options를 받아서 리패칭 타임, 중복 fetch 방지등 기능을 추가하였습니다.
하지만 이 과정에서 어떻게하면 최소한의 보일러 플레이트로 query를 담을 store를 자동 생성하며, key값에 따른 데이터들을 어떤 방식으로 관리를 할 것 인지 고민을 하게 되었습니다.
초반 fetch만을 위한 로직이기 때문에 간단한 queryMiddleware 함수를 만들어 fetch 함수를 감싸서 처리해주는 방향으로 제작하였습니다. try catch를 사용해 성공, 에러를 반환해주었고 성공 시 마지막 업데이트 시기를 추가하여 staletime을 통해 리패칭 타임을 설정해주었습니다. 그리하여 간단한 보일러 플레이트만으로 fetch함수에 대한 결과 값을 zustand에 캐싱하여 단 한 번의 fetch에도 전역적으로 접근 할 수 있게 되었습니다.
피드백
해당 기능을 제작 후 부트캠프의 튜터님께 리뷰를 받는 시간을 가졌습니다. 해당 리뷰에서 받은 피드백은
- 타입 명시를 zustand에서 확장하는 방향으로 제작하기
- zustand 내부에 캐싱되어 있는 값을 서버 상태로가 아닌 key만을 참조해 받아 올 수 있게하기
- 타 상태 관리 라이브러리에서 의존성 주입의 방식을 참고하기
- tanstackQuery를 사용하지 않을 독창적인 기능 추가하기
- fetch함수를 내부적으로 batching하여 순차적으로 실행 후, 동일 key값을 가진 fetch함수가 동시에 실행 되었을 때에도 중복 처리되지 않게 하기
- 초반 기능이 많이 없을 때에 여러 인터페이스를 생각해보며 외부 사용성을 위주로 리팩토링 해보기
정도가 있습니다.
마무리
실무에서 쓰는 zustand를 딥다이브하며 그에 의존 & 확장하는 라이브러리를 제작해보니 확실히 자세히 공부하며 깊게 파들어가야지 재미있구나 라는 생각을 가지게 되었습니다. 더 나아가 tanstackQuery에서 mutation에 해당하는 서버 통신 동기화 부분과 낙관적 업데이트를 내부적으로 지원하도록 추가할 예정입니다.
