-
-
Notifications
You must be signed in to change notification settings - Fork 454
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
(core) - Add built-in gql tag function #1187
Conversation
🦋 Changeset detectedLatest commit: 4b18626 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
3cc3b95
to
57ab05c
Compare
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 is superb
We tried replacing Do you still recommend using |
Yes exactly, duplicate identical fragments. I was wondering if it was intentionally left out :) |
@zachasme well, I hope that with the patch this is going to work just fine now ✌️ I hope that didn't waste any time on your part and will work as expected |
Wow that was fast, and it appears to be working--thanks a bunch, @kitten! 👍 No time wasted, I only did a quick search+replace on our develop branch last week to try it out, and wrote the comment to figure out what was happening. |
Summary
No RFC, since this is a rather small change that naturally emerged after #1186
We can merge the functionality of
graphql-tag
into a leaner function in@urql/core
. Our implementation does not check fragment names globally, so that it works well with@urql/exchange-graphcache
but mostly checks them in the document that's currently generated.The output is still compatible with
graphql-tag
and works similarly. There's potential for more optimisations, but the most important optimisation is that the function reuses the key-cache ofrequest.ts
in the same file.The size increase is negligible and could be gained back with more refactors potentially (0.1kB gzip)