You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Converting this to the app router actually looks pretty similar, we just need to move things around a bit. First, we'll create a Server Component to do the prefetching part:
158
162
159
163
```tsx
160
-
// app/posts/page.jsx
164
+
// app/posts/page.tsx
161
165
import {
162
166
dehydrate,
163
167
HydrationBoundary,
@@ -186,7 +190,7 @@ export default async function PostsPage() {
186
190
Next, we'll look at what the Client Component part looks like:
187
191
188
192
```tsx
189
-
// app/posts/posts.jsx
193
+
// app/posts/posts.tsx
190
194
'use client'
191
195
192
196
exportdefaultfunction Posts() {
@@ -221,7 +225,7 @@ In the SSR guide, we noted that you could get rid of the boilerplate of having `
221
225
A nice thing about Server Components is that they can be nested and exist on many levels in the React tree, making it possible to prefetch data closer to where it's actually used instead of only at the top of the application (just like Remix loaders). This can be as simple as a Server Component rendering another Server Component (we'll leave the Client Components out in this example for brevity):
222
226
223
227
```tsx
224
-
// app/posts/page.jsx
228
+
// app/posts/page.tsx
225
229
import {
226
230
dehydrate,
227
231
HydrationBoundary,
@@ -246,7 +250,7 @@ export default async function PostsPage() {
246
250
)
247
251
}
248
252
249
-
// app/posts/comments-server.jsx
253
+
// app/posts/comments-server.tsx
250
254
import {
251
255
dehydrate,
252
256
HydrationBoundary,
@@ -290,7 +294,7 @@ As more frameworks start supporting Server Components, they might have other rou
290
294
In the example above, we create a new `queryClient` for each Server Component that fetches data. This is the recommended approach, but if you want to, you can alternatively create a single one that is reused across all Server Components:
@@ -310,7 +314,7 @@ Next.js already dedupes requests that utilize `fetch()`, but if you are using so
310
314
With Server Components, it's important to think about data ownership and revalidation. To explain why, let's look at a modified example from above:
311
315
312
316
```tsx
313
-
// app/posts/page.jsx
317
+
// app/posts/page.tsx
314
318
import {
315
319
dehydrate,
316
320
HydrationBoundary,
@@ -367,7 +371,7 @@ As of React Query v5.40.0, you don't have to `await` all prefetches for this to
367
371
368
372
To make this work, we have to instruct the `queryClient` to also `dehydrate` pending Queries. We can do this globally, or by passing that option directly to `dehydrate`.
369
373
370
-
We will also need to move the `getQueryClient()` function out of our `app/providers.jsx` file as we want to use it in our server component and our client provider.
374
+
We will also need to move the `getQueryClient()` function out of our `app/providers.tsx` file as we want to use it in our server component and our client provider.
371
375
372
376
```tsx
373
377
// app/get-query-client.ts
@@ -415,7 +419,7 @@ export function getQueryClient() {
415
419
Then, all we need to do is provide a `HydrationBoundary`, but we don't need to `await` prefetches anymore:
0 commit comments