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
- useQuery picks
params, queries and use it to produce the queryKey.
- The
pick function would at least return an empty object even if the obj is undefined
- 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.
The Bug
Here is a reproduction CodeSandbox.
The bug is caused by explicitly passing
undefinedas config to auseXXX. But not ongetKeyByXXXWorkaround
Explicitly pass
{}togetKeyByXXXas config.The workaround would NOT work if I try to
getKeyByXXXon a immutable query. It's becauseuseImmutableQueryadditionally appendbodyto its queryKey.The Root Cause
For
useXXXparams,queriesand use it to produce the queryKey.pickfunction would at least return an empty object even if theobjisundefinedundefinedconfig ofuseXXXproduce a{}in its queryKeyFor
getKeyByXXXIt essentially do the same as
useXXX. But it checks ifconfigis passed and then make it part of queryKey.Possible Solution
At first, I believe there is a bug on
pickimplementation. If theobjisundefined, it should returnundefined, too.Fix the Mismatch Behavior between
useXXXandgetKeyByXXX.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.