리액트 서버 컴포넌트가 리액트 쿼리를 없앨까요? 아마 지난 몇 달 동안 제가 가장 많이 받은 질문일 것입니다.
그리고 기억해야 할것은, 정답은 없습니다. 기억하세요. 이 업계의 많은 개발자 분들처럼 저도 그냥 만들어내가고 있을 뿐입니다.
제가 모든 일에 대해 엄청난 계획을 세웠다고 생각하신다면 실망하실 거에요. 저도 결국엔 이 일이 어떻게 될지 궁금할 뿐입니다.
TkDodo 트윗
데이터 페칭 분야 라이브러리의 메인테이너로서 서버컴포넌트와 서스펜스에 대해서 가장 큰 두려움을 느끼고 있습니다.
이것들이 리액트-쿼리와 어떻게 동작할것인가는 좋은 질문입니다. 제가 좋은 대답을 가지고 있을것 같지만 그러지 않네요.
이 말인 즉슨, 저는 이 주제를 조금 더 가까이 살펴보고, 이 주제를 저보다 훨씬 더 많이 아시는 분과 이야기를 나눴습니다.
저는 이제 이 주제에 대해 제 의견을 전달할 만큼의 편안함을 가지게 됐어요. 하지만 이건 어디까지나 제 생각입니다.
- 제 생각
우리가 사용하고 있는 모든 도구들은 우리가 갖고 있는 문제들을 해결하는데에 도움이 될것입니다 .
전통적으로, 리액트는 당신의 어플리케이션에서 어떻게 데이터를 가져오느냐에 대한 부분에선 의견이 없었습니다.
여기 useEffect가 있으니까 너가 원하는대로 해봐 라는 식이었죠.
이것이 리액트 커리나 swr 같은 라이브러리들이 탄생한 시기입니다. 이것들은 큰 격차를 메웠고, 빠르게 채택되었습니다.
그들의 DX나 사용자들을 위한 개선때문에요.
React Router 또한 비슷한 범주에 속합니다. "뷰" 라는 라이브러리가 우리에게 해줄수 있는것이 없을때 라우팅의 필요성을 해결해 주었습니다.
SSR이 등장하면서, 우리는 페이지 초기 로딩 속도를 높이고, 서버에서 html을 프리렌더링 하는데에 초점을 맞췄습니다.
그 후에 우리의 어플리케이션은 클라이언트 사이드 페이지 네비게이션 등을 포함해서 완전한 SPA처럼 동작했습니다.
이럴 때도 리액트 쿼리가 중요한 역할을 합니다. 당신은 초기 데이터를 서버로 가져와서, 클라이언트에게 fetch 된 결과물을 하이드레이트할수 있도록 합니다.
이것은 서버에서 가능한 빨리 캐시를 채우는 좋은 방법 입니다.
- 그렇다면 무엇이 변화했는가 ?
시간이 지날수록, 많은 것들이 더 나아집니다. 앞뒤로 움직이는 것처럼 보일지라도, 사실은 앞으로 나아가는 중입니다.
swyx 트윗
저는 @Mappletons 가 더 잘할수 있다고 확신하는데, 개발자들은 끝없이 왔다 갔다 한다라는 댓글을 볼때 마다 제 머릿속에선 이러한 장면이 떠오릅니다.
리액트는 아직도 컴포넌트들을 렌더링 하기 위한 라이브러리이지만, 서버컴포넌트가 등장하고 서버에서 바로 렌더링할수 있도록 되면서 새로운 어플리케이션 구조를 제공하게 되었습니다.
클라이언트에서 쿼리를 해야하는 API 빌드 없이, 빌드타임이나 런타임에 데이터에 접근할 수 있도록 합니다.
export default async function Page() {
const data = await fetch(
`https://api.github.com/repos/tanstack/react-query`
)
return (
<div>
<h1>{data.name}</h1>
<p>{data.description}</p>
</div>
)
}리액트 컴포넌트 내에서 async/await을 사용한다는 것 자체가 아직도 놀랍고, 프레임워크들이 이러한 문제들을 포착하고 솔루션들을 제공하는 것을 보는것은 매우 흥미롭습니다.
이것은 이 아키텍쳐를 채택하는 어플리케이션에 대한 것들을 급격하게 변화 시킵니다.
리액트는 무엇보다, 클라이언트에서 비동기적인 상태를 관리하는 라이브러리입니다.
만약 당신의 데이터페칭이 서버에서만 발생하는거라면, 왜 이게 필요할까요 ?
- 당신은 아마 필요 없을 수도 있습니다.
정답은, 아마 당신은 필요 없을수도 있습니다. 만약 당신이 새로운 어플리케이션을 시작한다면, 그리고 당신이 Next.js 나 Remix 같은 데이터 페칭에 유용한 프레임워크들을 사용하고 있다면, 아마 React Query는 필요 없을 것 입니다.
그리고 이건 완전히 괜찮습니다.
저는 제가 리액트 커리를 관리한다고 해서 당신이 모든 상황에서 리액트 쿼리를 사용하라고 이 글을 작성한게 아닙니다.
만약 당신이 그걸 사용하기로 결정했다면, 그것은 당신의 문제를 해결하는데에 도움이 되어야합니다.
- 통합
아직도 서버컴포넌트와 리액트 쿼리를 통합 할 수 있는 공간은 많습니다.
첫번째로, 대부분의 프로젝트는 백색 도화지의 상태에서 시작하지 않습니다. 아직도 몇년동안 구축해온 많은 어플리케이션들이 있을 것이고 점진적으로 app directory를 채택할수는 있지만 서버 컴포넌트를 사용하기 위해선 어느정도의 재구성이 필요합니다.
이러한 전환 기간 동안 리액트 쿼리는 app directory와 서버컴포넌트들을 잘 통합 시킬 것 입니다.
당신은 몇몇 컴포넌트들을 옮겨서 서버에서만 fetch 되도록 할 수도 있고, 아니면 useQuery를 사용하는 클라이언트에게 당신의 캐시를 프리페치해서 받은 결과를 전달하도록 서버컴포넌트들을 사용할 수 있습니다.
모 아니면 도일 필요는 없습니다. 공식문서에서는 이미 이러한 통합에 대한 좋은 가이드가 있고, 주의 사항에 대한 글들을 작성 함으로써 후속 조치를 할 것입니다.
- 하이브리드 접근
이 하이브리드 접근법은 서버 구성 요소에서 아직 제대로 지원되지 않는 사용 사례를 사용하는 경우 특히 유용할 수 있습니다.
예를 들어서, 만약 당신이 서버에서 첫번째 페이지에 대해서는 프리페치를 해오는 무한 스크롤을 렌더링 하고 싶고,사용자가 스크롤을 더 내리면 내릴수록 더 많은 페이지들을 요청해오고 싶을 수 있습니다.
아니면 당신이 네트워크 연결이 되어 있지 않은 환경에서 작업을 해야할 수도 있습니다.
또한 당신은 명시적인 사용자 상호 작용 없이도 항상 새로운 데이터를 보는 사용자 환경을 좋아할 수 도 있습니다. (일정한 간격으로 데이터를 페칭하는 거나, 리액트 쿼리에서 자동으로 리페칭 해오는 것을 생각해보세요)
리액트 쿼리는 이러한 상황들에 대해서 좋은 설명들이 존재하고, 그러므로 서버 컴포넌트들과 결합하는 것이 타당한 경우들이 있습니다.
하지만 만약 리액트 쿼리를 데이터 페칭과 페칭 해온 데이터를 유저에게 보여주는것에 대해서 주요한 기능으로 사용한다면, 제 생각에는 서버컴포넌트가 그걸 잘 대체 해줄 것이라고 생각합니다.
그리고 mutaion(server action)이 안정되게 확립 된다면, 데이터를 업데이트 하기 위해서도 필요하지 않을수 있습니다.
- 킬러는 아닙니다.
다양한 이유들로 인해서 모든 사람이 서버 컴포넌트를 채택하지 않는다는 것은 정당하다고 생각합니다.
만약 당신의 백엔드 환경이 nodeJs가 아니고 프론트 엔드 환경이 전용 서버가 없는 SPA 인 경우도 괜찮습니다.
만약 당신이 리액트 네이티브로 모바일 앱을 만들고 있을 수도 있습니다. 만약 당신이 TanStack Query 사용자라면, 리액트를 전혀 사용하지 않을 수도 있습니다.
게다가, 당신은 데이터 페칭 외에도 React Query를 사용할 수 있습니다. 영감을 얻기 위해 이 트윗 글을 살펴보세요.
TkDodo 트윗
리액트 쿼리를 데이터 페칭이 아닌 다른 용도로 사용하는 경우는 어떤게 있을까요? 어떤 경우들이 있을지 궁금합니다.
이 모든 사례들은 클라이언트에서 비동기로 상태를 관리하는데에 리액트 쿼리를 사용한 좋은 사례들입니다.
하지만 이 기능이 이미 내장된 프레임워크를 사용하기로 했다면, 그걸 사용하세요!
제 말은, 왜 remix를 사용하면서 그 안에 있는 loader들을 통해 데이터를 요청하지 않을 이유는 무엇인가요 ?
그래서, 저는 쿼리와 리액트 서버컴포넌트들을 결합해서 사용하거나, 그 밖에서 사용하는 경우도 많을 것이라고 생각합니다.
현재까지 이야기들은 모두 리액트 서버컴포넌트에 대한 것들이지만, 모두가 사용해보고 싶어하는 빛나는 기술이니 괜찮습니다.
그래도 리액트 서버 컴포넌트는 도입중인 기술입니다. 그것들을 사용하기 위해선 주어진 프레임워크, 라우터, 번들러들과 함께 결합해야합니다.
이것은 추가적인 서버 부하를 처리할 수 있는 인프라가 있어야한다는 것을 의미합니다. 저 스스로에게 반복하는 말이지만
공짜 점심은 없다. 모든것엔 트레이드 오프가 존재한다.
그래서, 모든 것들을 즉시 서버컴포넌트들로 옮길 필요는 없습니다. Next..js 유저로서, app directory로 우리의 앱을 옮기게 되어 기쁩니다. 특히 중첩 라우팅의 장점을 누릴수 있어서요.
그리고 저는 staleTime : Infinity 속성을 가진 조금 더 정적인 데이터 페칭은 서버 컴포넌트로 옮길 예정입니다.
그래도 리액트 쿼리의 사망 선고는 좀 과장 된것입니다. 
