-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Migrate cache to Apollo v3 #2656
Comments
I am seeing a lot of "Invariant Violation" errors from Apollo 3 in the browser console. They are not causing breaking errors, but they are an indication that the Apollo client cache is probably not operating efficiently. So the point is that we need to move on this sooner rather than later. In addition, there are other vestiges of Apollo 2 like I could probably make these changes, but I can't commit to starting right away because of other deadlines I have. But if I do start on this, how do I make sure that no-one else is doing the same work? To discuss that question further, I will open another issue. |
Contribution on Apollo v3 would be muuuch appreciated. If you start something, I would simply suggest releasing a patch version of Vulcan current code before we merge the work, and then release a minor. It's ok to have breaking change, as long as we rely on semantic versioning. There is also a MIGRATING.md where you can explain breaking changes manually + the automated changelog. |
Is your feature request related to a problem? Please describe.
We need to update Apollo client cache system to v3. The problem is that there is a breaking change, there is no fragment matcher anymore: https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#breaking-cache-changes
End user must be able to provide "possibleTypes" instead.
Also, updating the cache directly lead to
writeData
is not defined for hooks optimistic update.Describe the solution you'd like
So:
(note that in Next we avoid such issues by letting the user create its own client ; creating it in Vulcan core is convenient but makes tweaking diffficult).
apollo-cache-*
deps when doneAdditional context
https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#breaking-cache-changes
The text was updated successfully, but these errors were encountered: