바야흐로 2023년... next js 를 app router 로 입문을 했다. 문서도 보고 강의도 보고 코드를 짜면서 이것이.. 이렇게 쓰는게 맞는지여..? 하며 개발을 했던 기억이 난다.
그때 명백히 배웠던 것이, next를 사용할 때는 axios 나 tansctack query를 쓸 필요 없이 fetch
하나만으로 api 연동 구현이 가능하다는 점이었다. 그렇기 때문에 작년 중반? 까지는, next에서 tanstack query를 사용할 필요가 없다고 생각하였다.
하지만, 다른 블로그 글도 보고 새로운 유투브 강의도 보며 느낀 것은 tanstack query를 next 에서 ssr과 함께 사용할 때 이점이 여러모로 있다는 것이다.
사실 tanstack query가 제공해주는 캐싱, 재검증과 같은 기능은 next.js 가 제공하는 확장된fetch
만으로도 충분하다.
기존의 Tanstack Query는 "클라이언트에서 데이터를 관리"하는 라이브러리였다.
next.js의 서버 컴포넌트를 사용하면, 데이터를 클라이언트에서 가져올 필요 없이, 서버에서 바로 가져와 UI에 렌더링할 수 있다.
즉, useQuery
없이도 서버에서 데이터를 불러오고, 클라이언트에서 추가적인 네트워크 요청 없이 즉시 표시할 수 있다.
서버에서 가져온 데이터를 클라이언트에서 재사용하고 싶을 때 (Hydration)
Next.js에서 SSR을 사용하면 초기 데이터를 서버에서 가져오지만, 클라이언트에서 다시 요청이 발생할 수도 있다.
이때, Tanstack Query의 dehydrate
기능을 사용하면 서버에서 가져온 데이터를 클라이언트에서도 그대로 사용할 수 있다.
페이지네이션이 필요할 때
Next.js의 서버 컴포넌트는 한 번 데이터를 가져오면 끝이지만, 무한 스크롤 같은 기능은 지원하지 않는다.
물론, fetch
로도 가능하지만 더욱 편리한 기능과 최적화된 기능을 사용하여 더욱 고도화 시킬 수 있다!
fetch가 이미 익숙한 사람이라면 굳이 tanstack query와 함께 사용하지 않아도 된다. 이는 tanstack query 공식문서에서도 확인할 수 있다. 하지만, 본인이 이미 Tanstack query에 익숙하면서, data를 fetching 할 때 조금 더 까다로운 형태를 구현해야할 때 사용하면 좋다.
필자도 그동안 기본 fetch
를 이용해왔었는데, 이번에 SSR로 페이지를 렌더링할 때, 데이터를 사전에 미리 가져오면서 이를 클라이언트에서 사용할 수 있도록 hydration
하는 방식을 사용하려고 있다. 이 부분을 공부하면서 여러 크고 작은 문제들을 겪었는데, 아주 많은 포스트거리가 생겨서 좋았다.