Apollo Client 2.0 getInitialState for SSR with Next.js

[jthegedus]

Intended outcome:

Upgrade the Next.js with-apollo example to use Apollo Client v2.0.0.

Actual outcome:
Everything works, I just would like some feedback on the method used.

Originally I followed the Apollo Client v2 upgrade guide and implemented the recommended

import ApolloClient from "apollo-client";
import InMemoryCache from "apollo-cache-inmemory";

const cache = new InMemoryCache();
const client = new ApolloClient({ cache });

// do some data loading things using getDataFromTree

const state = cache.extract();

however found a discussion from the Apollo apollo-client-core Slack channel that said you could extract the state from the cache through the client:

const state = apollo.queryManager.dataStore.getCache().extract()

Since this is simpler I've implemented the latter. The pending PR is here vercel/next.js#3029. Any comments before it gets merged on whether or not this is a valid method for grabbing the state from the cache would be good. It's much nicer to only have to export the ApolloClient object from the https://github.com/zeit/next.js/pull/3029/files#diff-5cdabd33c0ae9862f9c98f19dff96b85 file, instead of the storing and exporting the cache itself too.

Thanks for your time!

Version

• apollo-client@^2.0.0-beta.3

[jbaxleyiii]

@jthegedus hmm this is an interesting point. I didn't expect keeping the cache reference around to be a problem but I do see that adding a quick method would be nice.

How about I implement something like this:

import ApolloClient from "apollo-client";
import InMemoryCache from "apollo-cache-inmemory";

const cache = new InMemoryCache();
const client = new ApolloClient({ cache });

// do some data loading things using getDataFromTree
client.cache.extract()

That way cache is publicly attached to the client instance to be used as needed

[jbaxleyiii]

cc @peggyrayzis for the upgrade guide / githunt work

[jthegedus]

Keeping the cache around isn't really a problem, but if it's not necessary because of apollo.queryManager.dataStore.getCache() then why split the functionality? If this type of usage is expected to remain available and stable, I don't see why I would want to track the cache separately (given what I currently understand, I could certainly be wrong).

Having the cache attached to the client in that manner would be more convenient than the queryManager.dataStore.getCache() method. Unless there are plans to support multiple caches on a single client object I don't see the harm.

[jbaxleyiii]

The idea was that you typically define the cache where you need to extract the data, but that may not always be the case. I think attaching it to the client and recommending that as the official way is the best / easiest bet!

Thanks for the idea!

[jbaxleyiii]

@jthegedus updated with #2281

Both previous ways will work, but once that beta is out, you can do client.cache.extract() and I've updated the upgrade guide to use it as the primary method