fix: add empty object in place of variables for more consistent keys#894
fix: add empty object in place of variables for more consistent keys#894rliljest wants to merge 1 commit intodotansimha:mainfrom
Conversation
🦋 Changeset detectedLatest commit: 761b305 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Is there anything that I'm missing to get this PR approved and merged? The issue that this resolves persists |
|
@TkDodo thoughts? |
|
looking at the linked issue, if you want to treat and the same, I guess this change is what you want. A real-life example would be helpful though. Like, why isn't the argument for
agree with that sentiment, too. |
| ) => { | ||
| return useQuery<CurrentUserForProfileQuery, TError, TData>( | ||
| variables === undefined ? ['CurrentUserForProfile'] : ['CurrentUserForProfile', variables], | ||
| variables === undefined ? ['CurrentUserForProfile', {}] : ['CurrentUserForProfile', variables], |
There was a problem hiding this comment.
why not default variables to {} to avoid the extra check:
variables?: CurrentUserForProfileQueryVariables = {},
return useQuery(['CurrentUserForProfile', variables])
There was a problem hiding this comment.
Updated and rebased changes to follow your suggestion
795ba53 to
803a3cd
Compare
That would be another valid solution to the underlying issue. The main reason why I took the approach I did in this MR was to avoid breaking changes by forcing users to supply an empty object when they did not previously. Another thing to consider is that currently in the codegen there is no differentiation between a query that takes no arguments vs. a query that takes no required arguments. So that approach would require users to provide an empty object on queries that do not take any arguments at all, which seems like an unnecessary breaking change |
|
@saihaj Anything outstanding that I can explain/address to get this approved and merged? |
Description
Addresses potential issues stemming from mismatched generated keys.
Related #866
Type of change
Please delete options that are not relevant.
NOTE: Does have a fairly minor breaking change in case clients were hard-coding keys (not using generated helpers) and specifying "exact" react-query key matching
How Has This Been Tested?
Automated tests have been updated to accommodate this change
Test Environment:
@graphql-codegen/typescript-react-query: 6.1.0Checklist:
CONTRIBUTING doc and the
style guidelines of this project