search

VulcanJS / Vulcan

🌋 A toolkit to quickly build apps with React, GraphQL & Meteor
http://vulcanjs.org
MIT License
7.98k stars 1.88k forks source link

Migrate cache to Apollo v3 #2656

Open eric-burel opened 3 years ago

eric-burel commented 3 years ago

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:

  1. Adding a new method to register some possible types? Pass them at client creation? (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).
  2. remove apollo-cache-* deps when done
  3. replace cache "writeData" by writeQuery (as it is already done in Vulcan NPM: https://github.com/VulcanJS/vulcan-npm/blob/devel/packages/react-hooks/multiQueryUpdater.ts), this part will be easy

Additional context https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#breaking-cache-changes

ErikDakoda commented 3 years ago

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 apollo-link-state that we should probably deprecate from the Vulcan code (see https://github.com/apollographql/apollo-client/pull/5982). In this case it's possible that nobody in Vulcan land is using link state - but how do we find that out? Is it safe to just remove this feature?

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.

eric-burel commented 3 years ago

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.