-
-
Notifications
You must be signed in to change notification settings - Fork 36
fix: reuse helper to generate keys in prefetch hooks #103
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
3588856
reuse function to generate keys
nopitown 6a7562d
Merge branch 'main' into nopitown-fix-prefetch-query-keys
7nohe 9b0af8b
chore: Remove queryKey parameter from prefetch queries
7nohe 7e6d53d
chore: Format code
7nohe b46eff7
chore: Remove unused imports
7nohe 58668d2
chore: Format code
7nohe File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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 have the queryKey parameter?
I understand the want to make the prefetch match the query hooks.
Do you envision using this on prefetch requests?
Have you used the queryKey parameter on the query hooks?
I am wondering if we need that at all (even for query hooks)
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.
Well, in the case of the prefetch, we need to mirror what the query hook does, so if the query hook supports it, we expect to also be able to prefetch queries with the same key. Having said that, I think I have used the custom
query key
param just a few times when I found the autogenerated one not easy to read. I guess the idea was to give devs the flexibility to use the query keys based on the query string or set their custom one, which I think is fantastic.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.
@7nohe any comments on this?
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.
I believe that having a queryKey is necessary for flexibility. Since normal queries accept a queryKey, we should conform to that as well.
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.
I am in agreement but I would like to understand use cases where we would need a specific queryKey outside of the generated one and the query request params.
My argument against the 'flexibility' is that it pollutes the code and pollutes the API.
If someone needs more flexibility they should make their own hook.
I say we move forward with copying what the queries do and think about next major patch to remove the option to supply a queryKey.
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.
I can't come up with a specific case, but if I were to explain using the Next.js example I just added, using keys such as QueryA or QueryB rather than matching tags or limits makes it easier to manage the code.
app/page.tsx
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.
Thanks for the example.
I am failing to understand how it is 'easier' than using the generated key and properties.
When overriding, there will be queries and keys that do not match when these hooks are used in other places in code.
I feel it would be safer for the consumer to write their own hooks and preferences so they have complete control rather than us allowing them to configure keys that they would have to override every single use.
Uh oh!
There was an error while loading. Please reload this page.
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.
As you mentioned, that does seem to be the safer option. Since this library outputs pure TypeScript clients, it would be better to use them to build your own hooks.
It seems better to allow a queryKey option after finding some practical cases.
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.
@nopitown
Would you remove the
queryKey
parameter?The latest main branch includes the Next.js sample app. You can run it with the following command.
If you're busy, I can make the changes instead.