Skip to content
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

zodios-react key from useXXX is differ from getKeyByXXX #281

Open
QzCurious opened this issue Jan 9, 2023 · 6 comments
Open

zodios-react key from useXXX is differ from getKeyByXXX #281

QzCurious opened this issue Jan 9, 2023 · 6 comments
Labels
bug Something isn't working pinned issues that should not be closed by bot

Comments

@QzCurious
Copy link
Contributor

QzCurious commented Jan 9, 2023

The Bug

Here is a reproduction CodeSandbox.

The bug is caused by explicitly passing undefined as config to a useXXX. But not on getKeyByXXX

Workaround

Explicitly pass {} to getKeyByXXX as config.

The workaround would NOT work if I try to getKeyByXXX on a immutable query. It's because useImmutableQuery additionally append body to its queryKey.

The Root Cause

For useXXX

  1. useQuery picks params, queries and use it to produce the queryKey.
  2. The pick function would at least return an empty object even if the obj is undefined
  3. The explicit undefined config of useXXX produce a {} in its queryKey

For getKeyByXXX

It essentially do the same as useXXX. But it checks if config is passed and then make it part of queryKey.

Possible Solution

At first, I believe there is a bug on pick implementation. If the obj is undefined, it should return undefined, too.

Fix the Mismatch Behavior between useXXX and getKeyByXXX.

Both these two function needs to derive queryKey from config. So either copy paste the code one another . Or an helper method might be cleaner.

@QzCurious
Copy link
Contributor Author

Hope the context is enough for you to fix this. I'm sorry that currently I don't have time to do the PR.

@ecyrbe
Copy link
Owner

ecyrbe commented Jan 10, 2023

Thank you for taking the time to report this issue and also to create a reproductible example.
This will be fixed today as it should be an easy fix.
to evoid issues in the future, i'll share the code between the two.

@ecyrbe ecyrbe added the bug Something isn't working label Jan 16, 2023
@ecyrbe ecyrbe changed the title [Bug] zodios-react key from useXXX is differ from getKeyByXXX zodios-react key from useXXX is differ from getKeyByXXX Jan 16, 2023
@stale
Copy link

stale bot commented Feb 16, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Feb 16, 2023
@stale stale bot closed this as completed Feb 23, 2023
@ecyrbe ecyrbe reopened this Feb 23, 2023
@stale stale bot removed the wontfix This will not be worked on label Feb 23, 2023
@ecyrbe
Copy link
Owner

ecyrbe commented Feb 23, 2023

Sorry for delay, not as easy as i thought.

@stale
Copy link

stale bot commented Mar 25, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Mar 25, 2023
@ecyrbe ecyrbe added the pinned issues that should not be closed by bot label Mar 25, 2023
@stale stale bot removed the wontfix This will not be worked on label Mar 25, 2023
@not-paul-v
Copy link

Is there any update on this? Really liking the library so far but this "breaks" my hydration setup.

I investigated it a bit and it seems like in the getKeyByX methods there is a check whether config is undefined or not. But useQuery does not have that check. Could this be the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working pinned issues that should not be closed by bot
Projects
None yet
Development

No branches or pull requests

3 participants