update README to include PreloadQuery #303
Conversation
#217 Bundle Size — 1.07MiB (+6.53%).Warning Bundle contains 1 duplicate package – View duplicate packages Bundle metrics
|
| Current #217 |
Baseline #189 |
|
|---|---|---|
 Initial JS |
938.93KiB(+5.31%) |
891.55KiB |
| Initial CSS |
70B(+100%) |
0B |
 Cache Invalidation |
85.99% |
0.04% |
| Chunks |
32(+33.33%) |
24 |
| Assets |
56(+24.44%) |
45 |
| Modules |
591(+15.43%) |
512 |
| Duplicate Modules |
110(+266.67%) |
30 |
| Duplicate Code |
7.61%(+489.92%) |
1.29% |
 Packages |
26(-10.34%) |
29 |
 Duplicate Packages |
1 |
1 |
Bundle size by type 3 changes 3 regressions
| Current #217 |
Baseline #189 |
|
|---|---|---|
| JS |
1.06MiB (+6.3%) |
1MiB |
| Other |
8.67KiB (+44.68%) |
5.99KiB |
| CSS |
70B (+100%) |
0B |
Bundle analysis report Branch pr/readme-preloadQuery Project dashboard
| Before the child `ClientComponent` in the example renders, a "simulated network request" for this query is started in your Client Components. | ||
| That way, if you repeat the query in your Client Component using `useSuspenseQuery` (or even `useQuery`!), it will wait for the network request in your Server Component to finish instead of making it's own network request. | ||
|
|
||
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considerd "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. |
There was a problem hiding this comment.
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considerd "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. | |
| > [!IMPORTANT] | |
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considerd "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. |
I'd recommend an alert here to really call this out as something important. I chose IMPORTANT here, but WARNING or CAUTION also seems appropriate
| Before the child `ClientComponent` in the example renders, a "simulated network request" for this query is started in your Client Components. | ||
| That way, if you repeat the query in your Client Component using `useSuspenseQuery` (or even `useQuery`!), it will wait for the network request in your Server Component to finish instead of making it's own network request. | ||
|
|
||
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considerd "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. |
There was a problem hiding this comment.
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considerd "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. | |
| > Keep in mind that we recommend not to mix "client data" and "RSC data". Data fetched this way should be considered "client data" and never be referenced in your Server Components. In fact, `PreloadQuery` will create a separate `ApolloClient` instance from the instance normally used in RSC, to prevent mixing data. |
Typo
| </PreloadQuery> | ||
| ``` | ||
|
|
||
| > The `Suspense` boundary here is optional. |
There was a problem hiding this comment.
I wonder if we should explain why the Suspense boundary here is optional so we can let users know when it should be used. Is this only needed if ClientChild uses a useSuspenseQuery?
There was a problem hiding this comment.
It's just entirely optional. It would otherwise suspend up to the next suspense boundary, somewhere in the component tree.
| </PreloadQuery> | ||
| ``` | ||
|
|
||
| Inside of `ClientChild`, you could then call `useReadQuery` with the `queryRef` prop. The `Suspense` boundary in the example is optional. |
There was a problem hiding this comment.
Making the change to the example code, I'd either eliminate this, or move some of this info to a comment in the code block itself.
The
Suspenseboundary in the example is optional.
Like before, I'd recommend explaining when/why its optional. I'm actually surprised it is optional considering useReadQuery suspends on pending requests, so if I don't know when, I'm guessing our users won't either :)
|
|
||
| Inside of `ClientChild`, you could then call `useReadQuery` with the `queryRef` prop. The `Suspense` boundary in the example is optional. | ||
|
|
||
| #### Caveat |
There was a problem hiding this comment.
Is this caveat meant for PreloadQuery in general or just with the last section? I see this uses a heading level 4 which puts it at the same level as the other two sections, which means its part of the "Preloading data in RSC for usage in Client Components" section.
If this is meant for the query ref section, I'd consider removing this heading and putting the next sentence in either a block quote or NOTE alert
There was a problem hiding this comment.
It applies to both notations.
|
|
||
| #### Caveat | ||
|
|
||
| Keep in mind that this will look like a "new network request" to your Client Component, so make sure that the data you pass from your Server Components is not outdated, e.g. because of other caching layers you might be using. |
There was a problem hiding this comment.
I'm actually a little confused at what you're getting at here, mostly because some of this seems a little contradictory. You mention its a "new" network request, but yet it might suffer from being "outdated".
How would one make sure the data is not outdated and how would a user reconcile this? And is "other caching layers" referring to the Next.js fetch cache? Some more detail might be helpful here, otherwise you might consider removing this section to avoid confusion.
There was a problem hiding this comment.
Example: Your client component cache has up-to-date data from a recent mutation, and you get incoming data from an RSC that is already cached for days because the Next.js fetch cache didn't update.
There was a problem hiding this comment.
I hope 2528e36 helps a bit
Co-authored-by: Jerel Miller <jerelmiller@gmail.com>
No description provided.