-
Notifications
You must be signed in to change notification settings - Fork 181
fix: add empty object in place of variables for more consistent keys #894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not default variables to {}
to avoid the extra check:
variables?: CurrentUserForProfileQueryVariables = {},
return useQuery(['CurrentUserForProfile', variables])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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