Replace useFragment with Apollo's native#517
Replace useFragment with Apollo's native#517fidelman wants to merge 5 commits intomicrosoft:mainfrom
Conversation
e3b01ef to
d27d4dd
Compare
| "private": true, | ||
| "dependencies": { | ||
| "@apollo/client": "~3.6.0", | ||
| "@apollo/client": "3.8.1", |
There was a problem hiding this comment.
Is this the version we are using in TMP today? If not, I believe we agreed to use TMP's version and include a patch-package.
There was a problem hiding this comment.
nope, TMP uses 3.6.10. I gonna leave the graphitation as it is and patch it
There was a problem hiding this comment.
because dep-up duct-tape's Apollo will cause problem in TMP as it is patched there. Discussed w/@vladar so far the easiest way is to patch duct-tape's Apollo (btw it is already it is), and only dep-up duct-tape in TMP.
| "the fragment. Did you forget to invoke the compiler?", | ||
| ); | ||
|
|
||
| const client = useOverridenOrDefaultApolloClient(); |
There was a problem hiding this comment.
This is missing from the new implementation, and I do recall that I added this for a reason. It would be good to check the history for when I added this ability and see if there's a reason left in those commits.
There was a problem hiding this comment.
@alloy TLDR; we do not need that in the new implementation
My explanation
The old implementation were introduced by 3 commits:
- bf2f03e - replace
useStatewithobservableQuery.getCurrentResult(), commit text: Only trigger useState change when we really want it to - 21f61ee#diff-72832f4a1f9e169a840a8d60938b0a66249d0dc384d1cf3124f6ca049747f63f - replace forceUpdate with a dedicated hook, commit text: [apollo-react-relay-duct-tape] Implement useRefetchableFragment
- 87cb259, added a comment // Unclear why, but this yields twice with the same results, so skip one., commit text: [ARRDT] Cleanup
My assumption, correct me if you recall, The subscription was triggered twice (for unknown reason), so there is a logic to skip the first trigger and then forceUpdate triggers the hook again getting an actual value from the observableQuery.getCurrentResult();.
Here is how it looks without "skip". Just load and then the "Load more" button click
Here is how it looks w/ "skip" aka "old version":
And here is the logs of the new version:

As you can see it is identical to the old version, this is why I think we are good to remove that.
|
Great to see how simple this turned out to be! With this in place, and especially if we end up not needing to use TMP's patched Apollo version, I think we could actually go out and advertise duct-tape as something others could use. (But we'd need to discuss that more first.) |
| invariant( | ||
| typeof from === "string", | ||
| "useFragment(): Expected the fragment reference to have a string id. " + | ||
| "Did you forget to invoke the compiler?", | ||
| ); |
There was a problem hiding this comment.
fragmentReference.id is required for useFragment args to connect fragment with a query. @alloy do you think we can accept fragmentReference.id is nillable? Previous implementation did not have such invariant, but cache.watch did not require it either
| if (result.partial) { | ||
| invariant( | ||
| false, | ||
| "useFragment(): Missing data expected to be seeded by the execution query document: %s. Please check your type policies and possibleTypes configuration. If only subset of properties is missing you might need to configure merge functions for non-normalized types.", | ||
| JSON.stringify( | ||
| // we need the cast because queryInfo and lastDiff are private but very useful for debugging | ||
| ( | ||
| observableQuery as unknown as { | ||
| queryInfo?: { lastDiff?: { diff?: Cache.DiffResult<unknown> } }; | ||
| } | ||
| ).queryInfo?.lastDiff?.diff?.missing?.map((e) => e.path), | ||
| ), | ||
| ); | ||
| } |
There was a problem hiding this comment.
We must keep this invariant, but trigger it if useFragment returns !result.complete
sure it is! |
a3f6a95 to
6ee69a1
Compare
| dependencies: | ||
| "@babel/highlight" "^7.18.6" | ||
|
|
||
| "@babel/code-frame@^7.25.7": |
There was a problem hiding this comment.
I assume we can revert all changes to yarn.lock now that we have a patch?




useFragmentimplementation with Apollo's nativeuseFragmenthttps://www.apollographql.com/docs/react/data/fragments#usefragmentuseFragmentis stable there