remix_cache_sync.js

/*

Context is this brief twitter convo https://twitter.com/ryanflorence/status/1255655063021776897

It would seem like Remix would need a way to allow developers to sync their SSR'd initial data into a client-side 
GraphQL cache, like Apollo, if they're using one.  

For example, if you have

*/

export function load({ params }) {
  apolloClient.load(QUERY_1, params);
}

/*

Now QUERY_1 is in the remix cache, but not the GraphQL cache. That means if any downstream React component happens 
to run that same query, it won't be cached; a fresh network request will fire. This can get especially relevant when
you consider GraphQL fragments.

Would it make sense to allow routes to also export something like 

*/

export function syncCache(data, params){
  apolloClient.primeCache(/*...*/); // or whatever it is
}

/*

Of course those pairs of functions would get incredibly repetative, so, if you want to allow for an alternate api
to ameliorate that, you could allow devs to instead do something like

*/

export const load = {
  load({ params }){
    apolloClient.load(QUERY_1, params);
  },
  syncCache(data, params){
    apolloClient.primeCache(/* ... */);
  }
};

/*

Then devs would be able to come up with helpers to streamline this, without needing to repeat the same pair of load and 
sync exports everywhere, since ESM exports by definition need to be static. 

So devs could do something like 

*/

//appUtils.js (greatly simplified)

export default createRemixRouteLoader = query => ({
  load({ params }) {
    return apolloClient.load(query, params);
  },
  syncCache({ params }) {
    return apolloClient.primeCache(/* ... */);
  }
});

// gists.js

export const load = createRemixRouteLoader(QUERY_1);

/*

Obviously in practice createRemixRouteLoader would need to be a bit more complex - there'd in practice likely be
some manipulation of params into the real graphql variables, which would get injected into createRemixRouteLoader. 

But the idea is the same - hopefully that example is clear enough. 

*/