-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
fix(query-core): handle errors that occur inside setData
method
#7966
Merged
Merged
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
a9e281b
fix(query-core): add test case for not serializable data
Efimenko b04bf82
fix(query-core): handle `setData` error
Efimenko 02f6fa5
Update packages/query-core/src/__tests__/query.test.tsx
TkDodo 18ae646
fix(query-core): add `return` statement
Efimenko 87b241e
Merge branch 'issue-6954' of github.com:Efimenko/query into issue-6954
Efimenko 1ff334e
fix(query-core): throw the error in case when data is not serializabl…
Efimenko b0627f5
fix(query-core): delete packages/query-core/tsconfig.vitest-temp.json
Efimenko af4584a
Merge branch 'main' into issue-6954
Efimenko e733174
fix(query-core): lift serializability check and add console.error
Efimenko 3f2b14b
Merge branch 'issue-6954' of github.com:Efimenko/query into issue-6954
Efimenko 93d14ec
Merge branch 'main' into issue-6954
TkDodo 82d75b7
chore: message
TkDodo 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 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 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 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.
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.
This now throws an error when data contains BigInt. But it seems like react-query supports having BigInt in the query result. Should I create an issue for 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'm think it's still good to log the error because structuralSharing creates an overhead and you should likely turn it off if you have something that isn't serializable. But we should likely remove the throw. Logging is enough. Please file a PR
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.
Thank you @Efimenko for raising that PR 🙌
@TkDodo I have a question. From what I see in
replaceEqualDeep
, there's nothing leading BigInt comparison to break. For example,123n === 123n
will betrue
. Is there anything else I'm missing whereBigInt
could breakthis.setData()
?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.
interesting. I didn't know that BigInt was referentially equal, but not json serializable. According to the documentation, we only support json serializable values in
structuralSharing
, so I think the warning is still warranted.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.
Yeah, this seems to have affected a lot of upstream Wagmi users. Wonder if this should have been a breaking change. Changing from throwing to just a warning would be better though!
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.
It's "just" a dev mode warning. Why would it be breaking?
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.
Apologies. Didn't see this commit.
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.
@TkDodo – would you be open to a PR that checked for cyclic references instead of checking for non-serializable values via
JSON.stringify
? Feel like a lot of consumers would be invoking query functions that returnBigInt
s, so it might be a bit odd seeing these warning messages flying around whenreplaceEqualDeep
is also compatible withBigInt
s.Wonder if it’s worth conveying that structural sharing is moreso only compatible with referentially stable values instead of JSON-serializable values.
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 simply wasn't aware that
replaceEqualDeep
works withBigInt
- our general recommendation is to use json serializable values. If we say BigInt is supported, then why isn't Map supported, or Set, or Date, or ... it's a slippery slope. Also, in queryKeys, we actually useJSON.stringify
, so if you use a BigInt there, it will fail.Why is JavaScript so weird that BigInt is referentially stable across values, but not serializable lol.
yeah I guess that's fine. I think just calling
replaceEqualDeep
itself in a try/catch would just work, too ?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.
done! #8030