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.
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
Compare
DocumentNode
used inrefetchQueries
as strings #12236Compare
DocumentNode
used inrefetchQueries
as strings #12236Changes from 5 commits
d04679f
19d14a7
9f4b665
521b9d1
71f4652
ac07d25
75c3420
3c10ea5
7873f3c
8860968
1dfb266
b632d5d
af15100
17c8056
95cd778
03334ab
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 wasn't sure what to do here.
We don't have a way to differentiate query name from a
DocumentNode
anymore, so we can either always sayUnknown query
, check ifnameOrDoc
starts withquery
(<- the trailing space is important), or have the map holding an object instead of only a boolean:{ type, included }
.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.
Its probably a good idea to add a fallback name here that identifies it as anonymous, otherwise this might get unreadable for large queries. Here is a quick test I did with this change if you pass an unrecognized document node:
Even with this being a single field query, its already a bit unreadable.
That said, the old message wasn't much better 😂
Would you be willing to add an additional test case for an anonymous query document passed to
refetchQueries
that hits this condition? We probably should have had one all-along to prevent that monstrosity, but could be a good time to improve the error message while we're here.I think using "anonymous" as the fallback name would be ok since we've used "anonymous" in other places that print out query strings. We've got a
getOperationName
utility function that can extract it from a document node that can help determine if it has a name.Let me know what you think about that!
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.
To confirm the expectation, are you suggesting we keep only the branch
Unknown query named "%s" requested
for both cases? In other words, we never display the document node; we only show the query name or extract it from the document node viagetOperationName.
It gets noisy quickly. In most cases, an operation name would be more helpful than the entire document node.
If so, could it be problematic for an unknown anonymous query? E.g.:
Would produce:
How do we debug this if the query is anonymous and we don't show the content?
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.
Sorry for the confusion! Yes I'm suggesting we display this:
instead of this:
for the error message, at least for named queries. I was thinking we'd do the same for anonymous queries and show your 2nd suggestion there:
but I suppose showing the full query here isn't the end of the world.
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 you are correct.
Showing the full query only adds noise, and since warnings aren't shown by default, the URL leading to the error page is too long to be clickable. 😅
I've confirmed that the warning triggered by the invariant has a stack trace leading to the
refetchQueries
option. It should be enough to debug cases where we're tracking down an unknown query. In most cases, having the named query in a one-liner warning should be the optimal developer experience.I just sent a commit refactoring the logic mentioned above and added missing tests for warnings, including the anonymous query.
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.
Once we remove that check for
legacyOneTimeQuery
, we should be able to remove this as well sinceawait expect(stream).not.toEmitAnything()
will wait for 100ms on its own.