Apollo Client v3 Migration - Errors

[dougg0k]

Hi,

I tried to get offix working with Apollo Client v3 RC. But Typescript is throwing these errors.
I'm trying to implement in a ReactJS project.

(property) link?: ApolloLink | undefined
Type 'HttpLink' is not assignable to type 'ApolloLink'.
  Types of property 'split' are incompatible.
    Type '(test: (op: import("/projects/webapp/node_modules/@apollo/client/link/core/types").Operation) => boolean, left: import("/projects/webapp/node_modules/@apollo/client/link/core/ApolloLink").ApolloLink | import("/home/zephyrus/projects/webap...' is not assignable to type '(test: (op: import("/projects/webapp/node_modules/apollo-link/lib/types").Operation) => boolean, left: import("/projects/webapp/node_modules/apollo-link/lib/link").ApolloLink | import("/projects/webapp/node_modules/apollo-li...'.
      Types of parameters 'test' and 'test' are incompatible.
        Types of parameters 'op' and 'op' are incompatible.
          Property 'toKey' is missing in type 'import("/projects/webapp/node_modules/@apollo/client/link/core/types").Operation' but required in type 'import("/projects/webapp/node_modules/apollo-link/lib/types").Operation'.ts(2322)
types.d.ts(24, 5): 'toKey' is declared here.
ApolloClient.d.ts(17, 5): The expected type comes from property 'link' which is declared here on type 'ApolloOfflineClientOptions'

(property) cache: ApolloCache<NormalizedCacheObject>
Property 'writeData' is missing in type 'InMemoryCache' but required in type 'ApolloCache<NormalizedCacheObject>'.ts(2741)
cache.d.ts(22, 5): 'writeData' is declared here.
ApolloClient.d.ts(18, 5): The expected type comes from property 'cache' which is declared here on type 'ApolloOfflineClientOptions'

Implementation

import { HttpLink, InMemoryCache } from "@apollo/client";
import { ApolloOfflineClient } from "offix-client";

function getClient() {
	const client = new ApolloOfflineClient({
		link: new HttpLink({
			uri: "url",
			credentials: "same-origin",
		}),
		cache: new InMemoryCache(),
	});
	return client;
}

---

There was also an error in the ApolloProvider.

(JSX attribute) ApolloProviderProps<any>.client: ApolloClient<any>
Property 'setLink' is missing in type 'ApolloOfflineClient' but required in type 'ApolloClient<any>'.ts(2741)
ApolloClient.d.ts(72, 5): 'setLink' is declared here.
ApolloProvider.d.ts(4, 5): The expected type comes from property 'client' which is declared here on type 'IntrinsicAttributes & ApolloProviderProps<any> & { children?: ReactNode; }'

function App({ children }: { children: React.ReactNode }) {
	const [initialized, setInitialized] = useState(false);

	useEffect(() => {
		client.init().then(() => setInitialized(true));
	}, []);
	return initialized ? (
		<ApolloOfflineProvider client={client}>
			<ApolloProvider client={client}>
				{children}
			</ApolloProvider>
		</ApolloOfflineProvider>
	) : (
		<Loading />
	);
}

---

Any plans to get it compatible/working with it?

I think v3 is very close to release, they are on RC.9. In the Releases tab, they left this note.

Now that the release candidate phase of testing has begun, we will do our very best to avoid introducing any new features or breaking API changes, unless those changes are absolutely necessary to fix bugs.

[wtrocki]

Yes. We are actively trying to migrate to Apollo 3.0 and URQL but API changed so much that we need to design new system based off scheduler. Since Apollo 3.0 is just one big package you will get a lots of conflicts with classes that offix extends. We also use methods that Apollo team made private so we need to rewrite most of the code.

Long story short is that we actually doing active development to get things working with Apollo. We hoping to get something there in couple weeks.

In the meantime I will add a note to README that this library works with Apollo 2.0 and we are working on Apollo 3.0 integration

[dougg0k]

I understand. Sounds good, thanks!

[dougg0k]

It's out https://www.apollographql.com/blog/announcing-the-release-of-apollo-client-3-0/

[ThatMate]

Just found out this library. Can't wait to integrate it with my latest app.

[wtrocki]

I think as team we experimented with Apollo 3.0 and URQL. Since 3.0 is well established we will remove support to Apollo 2.0 and release offix 1.0 with support for those libraries. For the moment we are working on Offix datastore that has Firebase like API

[alonroth]

@wtrocki Any ETA on the Apollo 3.0 support? Thanks!!

[wtrocki]

TL;DR - Project is now shifting focus. We are planning Apollo 3.0 but it will not be added with the same API as Apollo 2.0

You going to get the same features and flexibility of current offix - with less reliance on specific version of the client.

There are a number of factors here so please forgive me for long answer.

Offix needs to diverge and change the approach a little bit. In the new office we will abstract from the graphql clients and move from apollo to general graphql (as we need to have a info about structure/ids etc.)

We we hitting some issues with Apollo client - private methods that we cannot access and some performance issues when using the current approach from offix.
That is why our team done firebase like approach to graphql called offix-datastore.

https://offix.dev/docs/next/datastore/introduction

This is still early alpha as we test it and bug-fixing it for the release this month.
This one exposes models that you can build upon and we hoping to add custom method resolutions using scheduler:

https://offix.dev/docs/next/offix/offix-scheduler-introduction

This way we will get offline mutations/edits for Apollo/URQL and even REST - while still integrating with reliable client side database solution - you can use cache if you wish still but persistence is db.

If you looking for Apollo 3.0 client migration that is probably not going to happen in 1-2 months, but we going to provide a comprehensive approach for client side database and replication - with problems that we think none of the clients resolve - things like updates for relationships, paginations optimistic responses are really hard on Apollo and most of the time our team were ending up helping other teams/companies to write them on top of apollo client (with some crazy amount of hacks for mitigating Apollo client bugs). The amount of time we helped other teams to write offix based solution could have been spent on writing better and more independent library.

We know that Apollo team also plans to work on the storage and read-only offline support (stuff that URQL has already) so we do not want to really compete with the client own features, but progress on those were slow.

Our scheduler can be used with the Apollo 3.0 already thus you going to get number of problems like need of mapping of the server side id's, cache invalidation on errors etc. that is simply going to consume a loot of time. As dev you can still pick it and make some simplification but providing generic and supportable solution here will require much more than that

[wtrocki]

Since there is a number of people on this issue already we will be looking for your feedback on what would be the preferred option here.

To make this more clear:

Current state

• We seen numerous people using offix without offline edits capability.
  This can be done using URQL already with much better performance

• As for the offline edits things starting to get complex and usually cache updates ending up very very complex - within offix we did not had any assumptions on the schema format and we really could not make offix to support all the use cases like relationships, pagination by just using cache.
  That is why we build db/store.

• Offix Scheduler that we considered a swiss army knife for people to use with any client but that ended up leaving to many questions unanswered thus requiring from developers to perform some extra actions that were not easy to document and support

Future

• Offix datastore

• Moving to a local store - model like API and hooks that simplify subscriptions aggregation. Imagine root level subscriptions that just give you data and no-hassle approach with cache strategies that might or might not work for you in production

• Enabling execution of graphql queries based on models with pulling out relationships, pagination etc.

[Vednus]

Is the new beta of offix (0.16.0) supposed to be working with @apollo/client? Looking through the code, it looks like it's still using older apollo packages. Will this beta eventually use the @apollo/client?

[alonroth]

@wtrocki are there any updates regarding Apollo Client v3 update?

[kingsleyzissou]

Hi all, we have made the decision to move away from the Apollo client and we have decided to deprecate our Offix packages and release our Datastore. This means that there are no plans to update Offix to support Apollo 3.0. I will be closing this issue, but if you have any questions, please feel free to let us know.

You can see the docs for the updated datastore here:
https://offix.dev/docs/getting-started