최근 zustand의 사용성을 향상시키기 위해서 미들웨어를 구현해보기로 결정했다.
지난 글에서 여러 라이브러리를 분석한 이유가 그래서이다.
일단 기본적으로 zustand 레포지토리에 있는 미들웨어들을 분석했었는데
대부분 기능에 대한 코드가 많기보다는 타입을 분류하는 조건문을 많이 작성되어있었다.
개발자들이 사용하는 상태관리를 위한 간단한 코드를 위해 라이브러리 개발자들이 피땀 흘려서 하나씩 하드코딩(?)을 하고 있던 것이다.
그래서 팀에서도 타입 지정과 구현 부분을 나눠서 해야할 것 같다고 계획했다.
일단 우리는 서버의 데이터를 동기화 시키기가 주된 목표였다.
사실 이미 react-query가 존재하고 있기 때문에 활용성의 의문점이 있을 수 있지만, zustand에서 서버 상태와 클라이언트 상태를 관리하게 된다면 기타 Boilerplate를 만들지 않아도 되기 때문에 이 부분에서 강점을 갖을 수 있다고 생각했다.
그렇기 때문에 맨땅에서 미들웨어 만들기보다 기존의 zustand store를 활용하여 store를 구독하는 형식으로 가닥을 잡았다.
또한 mutation을 통한 데이터 관리는 다음 스탭으로 생각하고 일단 queries을 통한 데이터 fetching을 우선적으로 처리하고자 했다.
그래서 현재 구현된 내용이
- 커스텀 훅을 사용하여 기존의
zustand와 비슷한 사용성 제공- 여러 컴포넌트에서 데이터를 참조해도
fetching은 한 번만 실행
(근데 최초 실행 시에는 사용된 모든 컴포넌트에서 실행 - 이 부분은 3 step)stale time을 설정하여 서버로부터 데이터를 자동fetching
이에 대한 내용을 확인하고 점검하면서 아래의 내용을 다시 한 번 리마인드 했다.
- 타입을 확장하는 방향
- useQuery는 사용성이 겹침
- store의 접근 제한 여부
- 정체성의 중요성 여부 - valtio등 의존성 주입의 방식을 찾아보아라
- queryfn을 받기 때문에 내부적으로 해당 fn을 동시 관리할 수 있는 무언가가 필요함. (일단 라이브러리의 인터페이스에 집중해서 외부 사용성만 1차 목표)
- zustand 의 확장 or zustand에 의존하는 라이브러리냐
결과적으로 우리 미들웨어의 사용성과 존재의 의미에 대한 내용이 비어있다고 생각이 들었다.
많은 개발자들이 사용하기 위해서 편의성도 좋지만, 이게 왜 필요하고 사용적인 측면에서도 의문점이 들면 서비스 제공 측면에서 불량품이라고 생각들기 때문에 개발 초반에 확인할 수 있어서 오히려 좋았다.
또한 오픈 소스로 단계별로 개발을 진행하면서 팀원들말고도 다른 개발자들의 생각? 경험?같은 내용도 추가될 수 있기에 해당 논의는 매우 중요했던 것 같다.
앞으로 이런 논의를 토대로..
어떤 고민을 담았냐 >> 이러한 과정이 포트폴리오
리서칭 과정 & 구현 과정은 실무와 밀접하니까 꼭 기록
정리를 해서 발표하면 상대에게 질문하고 싶은 곳을 만들어서 질문을 유도
