Feature/query client on context #8599
Conversation
closing over a queryClient should now error, as we pass the queryClient directly to the queryFunctionContext
|
View your CI Pipeline Execution ↗ for commit 840b47f.
☁️ Nx Cloud last updated this comment at |
|
Sizes for commit 840b47f:
|
github-actions
bot
added
documentation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8599 +/- ##
==========================================
- Coverage 46.29% 46.24% -0.05%
==========================================
Files 199 199
Lines 7539 7532 -7
Branches 1724 1720 -4
==========================================
- Hits 3490 3483 -7
Misses 3670 3670
Partials 379 379 |
| @@ -354,24 +354,6 @@ ruleTester.run('exhaustive-deps', rule, { | |||
| } | |||
| `, | |||
| }, | |||
| { | |||
| name: 'should ignore references of the queryClient', | |||
There was a problem hiding this comment.
note: we don’t need an exception for closing over the queryClient anymore if we inject it into the queryFn. @Newbie012 would you agree?
There was a problem hiding this comment.
I guess so. I never had to deal with more than one query client in a single app. Is it a valid use case to reference a foreign query client inside queryFn?
There was a problem hiding this comment.
nope, this is something the linter should definitely catch!
and try to bust it by changing sharedGlobals lol
| @@ -167,6 +169,7 @@ export class Query< | |||
| #initialState: QueryState<TData, TError> | |||
| #revertState?: QueryState<TData, TError> | |||
| #cache: QueryCache | |||
| #client: QueryClient | |||
There was a problem hiding this comment.
Would be nice to get a getter for QueryClient from the instance of Query.
I missed that before for experimental persister.
There was a problem hiding this comment.
you probably don’t need that now that it’s passed to the context, which the persister also has access to.
|
perfect timing, just went looking for this 🙏 |
|
I might argue that this is a breaking API change. We use @hey-api/openapi-ts, which generates API client functions out of an OpenAPI schema. The generated function accept a Before this change, we could do this: const { data, error } = useQuery({
queryKey: ['documents'],
queryFn: documentsControllerGetAll,
})But now the const { data, error } = useQuery({
queryKey: ['documents'],
queryFn: async () => {
return documentsControllerGetAll();
},
}) |
|
@jamesarosen in that sense, adding any parameter to any function would be a breaking change? |
I don't think there's a single easy answer. The orthodox rule is "removing or changing a feature is a breaking change; adding a feature is a non-breaking change." There are two ways to look at this change:
Postel's Law -- "Be conservative in what you send; be liberal in what you accept." -- might be relevant here. TanStack-Query is now sending (passing) something new. Then again, if the change in question were a new optional parameter to |
No description provided.