refactor: move queryOptions to its own file

[TkDodo]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
query	⬜️ Ignored (Inspect)			Jun 5, 2023 1:41pm

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit d26dc74. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx affected --targets=test:eslint,test:lib,test:types,test:build

---

Sent with 💌 from NxCloud.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: +6.37 🎉

Comparison is base (28e0e28) 88.86% compared to head (48ffbe2) 95.23%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##            alpha    #5480      +/-   ##
==========================================
+ Coverage   88.86%   95.23%   +6.37%     
==========================================
  Files          70       16      -54     
  Lines        2380      231    -2149     
  Branches      621       53     -568     
==========================================
- Hits         2115      220    -1895     
+ Misses        219       11     -208     
+ Partials       46        0      -46     

Impacted Files	Coverage Δ
packages/react-query/src/isRestoring.ts	100.00% <ø> (ø)
packages/react-query/src/queryOptions.ts	0.00% <0.00%> (ø)
packages/react-query/src/useQuery.ts	100.00% <ø> (+50.00%)	⬆️

... and 55 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[TkDodo]

I tried this out and the errors are way better if you have 'use client' in hooks and you try to use them in a server component. I'll just refactor queryOptions to a separate file instead

[Ephem]

I tried this out and the errors are way better if you have 'use client' in hooks and you try to use them in a server component. I'll just refactor queryOptions to a separate file instead

Sad to hear that, it's annoying, but I'm also happy I wasn't hallucinating about that part. 😅

So I guess the title of this PR is no longer up to date, it's now extracting queryOptions so it's usable on the server? I think it's looking good!

[TkDodo]

so with what we've learned at react summit:

• keep 'use client' for the HydrationBoundary
• add import client-only to the QueryClientProvider and to hooks.

is that about right?

[Ephem]

Yeah I think that's a nice approach. The reasoning for QueryClientProvider having import 'client-only' instead of 'use client' is that because it needs a queryClient as props and that can only be provided to it from another client component?

[TkDodo]

The reasoning for QueryClientProvider having import 'client-only' instead of 'use client' is that because it needs a queryClient as props and that can only be provided to it from another client component?

you need to create the QueryClient within the component, within state or a ref:

const [queryClient] = React.useState(() => new QueryClient());

which doesn't work in a server component anyways. Even if you try to create a new QueryClient() outside of the component, it still needs to happen in a client component, because otherwise, next will try to serialize the queryClient prop, and this is not possible, since it's a class instance. Errors are along the lines of:

error - Error: Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with "use server".
  {listeners: [], subscribe: function, config: ..., queries: ..., queriesMap: ...}
                             ^^^^^^^^
    at stringify (<anonymous>)

it works for HydrationBoundary because the state we pass to it is serializable per definition, however, I'm just seeing that we can also pass options to it, in which case it wouldn't work if the options are non-serializable. But I guess client-only would be a bit harsh for that component, since it works in some cases. But the Provider never works.

[Ephem]

Yep, just checking that we're on the same page. It has to be a Client Component, but it can never be a Client Boundary so to speak.

Hmm, the options to HydrationBoundary are indeed a problem.. I don't think I noticed when they were introduced so I don't know what use cases they support (why would you need to set specific queryOptions for these queries for example other than those that are automatically included in the dehydration? why the custom context support?), but if we need to keep these around, maybe we should bring back <Hydrate> as a import "client-only" version that supports options, and make <HydrationBoundary> not accept options and be the 'use client' version?

Just thinking out loud.

[TkDodo]

why would you need to set specific queryOptions for these queries

you can apparently set defaultOptions with which those queries or mutations should be hydrated:

query/packages/query-core/src/hydration.ts

Lines 18 to 23 in 4fa1cdb

	export interface HydrateOptions {
	defaultOptions?: {
	queries?: QueryOptions
	mutations?: MutationOptions
	}
	}

why the custom context support?

in v5, it's a custom queryClient (no more context). We added support to pass queryClient everywhere (even useQuery) so that you can use it in a situation where you don't want to rely on the queryClient from react context, e.g. in microfrontends.

maybe we should bring back as a import "client-only" version that supports options, and make not accept options and be the 'use client' version?

if you currently try to pass options to <HydrationBoundary>, it will fail if its in a server component (unless your options are in fact serializable, which they could very well be). In that case, you would need to move it to a client component. The error is not that nice, but I think most users won't use that, so I don't really see the problem tbh 😅

[Ephem]

Oh, I just noticed I hadn't answered this, I thought I did. 😅

so I don't really see the problem tbh

Yeah, I think you're right, I'm overthinking it. 😄

[TkDodo]

I'll merge this (moving queryOptions to its own file) and I'll do the actual use client / import client-only changes in a different PR that goes to main.