1. React-query

이유

1. 데이터 캐싱

   • 쿼리의 결과를 메모리에 캐싱하여 중복요청을 방지합니다.
   • 이전에 요청한 데이터를 다시 요청하지 않으므로 서버 부하를 줄일 수 있습니다.

2. Concurrent mode 지원

   • Suspense와 Errorboundary를 사용하여 비동기 컴포넌트를 보다 효율적으로 처리할 수 있다.

   

   → 기존의 코드를 가지고 에러, 로딩에 대한 분기처리를 할 경우 각 컴포넌트마다 세가지 상태에 대한 화면 보여주기 처리를 다 해주어야 합니다.

   → 이때 중복되거나 비슷한 에러 처리의 경우에도 일일이 적어야하는 코드량이 많아지고 가독성도 떨어집니다.

   → 하지만 리액트 쿼리의 경우 Suspense, Errorboundary를 제공, 에러를 선언적으로 처리할 수 있다는 장점이 존재합니다.

3. 에러 핸들링과 낙관적 업데이트

   • react-query에서는 onMutation, onSuccess, onError속성을 통해 비동기 요청에서 다양한 상황에 대한 대처가 가능합니다.
   • 낙관적 업데이트를 통해서 사용자 입장에서 좀 더 편안한 UX를 제공하면서 서버와 동기화를 쉽게 할 수 있습니다.

비교

• useSWR:
  • 앞서 설명한 React-query의 기능을 모두 제공합니다.
  • 하지만 useSWR은 리액트 쿼리에 비해 친절한 devtool를 제공하지 않습니다.
  • useSWR은 서버에서 받은 데이터를 클라이언트 상태로 바꿉니다. ( 이 경우 서버상태와 클라이언트 상태의 관심사 분리 판단, 서버 상태와 클라이언트 상태를 분리하는 React-query를 사용하였습니다.)
• RTKQuery
  • 리덕스 툴킷에 종속적인 라이브러리, 용량도 너무 커서 사용하지 않았습니다.

2. Zustand

전역 상태 라이브러리를 사용한 이유

depth 가 깊은 props drilling을 막고 유지보수성을 높이자

ex) 저희 셀럽잇 서비스는 지도에 있는 맛집과 음식점 리스트를 동기화 시켜주는 기능이 있습니다.

음식점 리스트 컴포넌트와 지도 컴포넌트는 경도, 위도, 그 외 여러가지 필터링 되는 요소에 데이터를 공유, 그 외 어떤 음식점이 hover되었는지 기타 등등 많은 요소들을 공유하고 있습니다.

이를 공유하기 위해서 두 컴포넌트를 묶는 최상위 컴포넌트에 대부분의 state를 공유, props drilling depth가 엄청나게 깊어져 갔습니다. (google map api…) → 유지보수성, 가독성 모두 안 좋아지고 있었습니다.

따라서 이를 해결하기 위해 전역 상태 라이브러리를 사용했습니다.

그 외 모달창, 팝업창 등 다양한 기능에도 이를 잘 활용할 수 있을 것 같아서 사용했습니다.

Zustand를 선택한 이유