React-apollo: Pass `extensions` to the client

[yorch]

Currently, our GraphQL server uses extensions property in the response payload to send extra meta data (like metrics and other stuff). I would need to consume this information on either the grapqhl HOC or the Query Component, but doesn't seem like it's exposed in any way.

I see the information in a custom link in our Apollo Client, but can't find a way to pass that info to the client (ie, I tried using context, but it seems like it's only one way communication, from HOC / Query component to Apollo Link).

Am I missing something?

Intended outcome:

Get extensions along side data, errors, loading in the graphql HOC and / or Query component.

Version

• [email protected]
• [email protected]

[djyde]

need it, too

[nikordaris]

I might look at this next week but if you can see the extensions data in the custom link then you probably can do something like this:

new ApolloLink((operation, forward) => new Observer((observer) => {
  const sub = forward(operation).subscribe({
    next: (result) => {
      // Some how get extensions passed from server
      result.extensions = extensions
      observer.next(result);
    },
    error: (error) => {...}
    complete: observer.complete.bind(observer),
  });
  return () => {
    if (sub) sub.unsubscribe();
  }
}));

then in theory you should have access to the extensions data along side data, error, and loading. If you try it out before I do let me know if it works!

[rosskevin]

Please feel free to PR a proposed solution that works for you and we can review it. Looks like an addition so it could be integrated without breaking changes.

[mhuggins]

@rosskevin Any pointers on where to start looking in the codebase for this? Happy to contribute to support this, but I've never worked on react-apollo internals before.

[rosskevin]

Minimally you will need to touch apollo-link and react-apollo, but perhaps apollo-client as well. @hwillson do you have some pointers here? This likely impacts several projects as a new feature and should have some design oversight.

[bsara]

I started looking through the code to see how difficult this would be. If I'm understanding things correctly, this a big update. The issue is not in the link. The link already forwards on extensions when it is received. The update seems to need to be in apollo-cache. The cache stores data from the response and ignores extensions altogether. Then, whenever data is retrieved to be passed to the child function of a Query component, it is retrieved from the cache. This means that extensions would need to be stored alongside or with data in the cache somehow. I'm brand new to the codebase, so I don't know what the complexities would be to add such a thing, but from my initial experimentation, it's not a small task, given the fact that the cache is itself a graph that can be queried against. I hope that I'm wrong about the difficulty of it though.

[sgrove]

@bsara That's correct if you're doing a real, correct solution. We wrote about our well-considered tradeoff-based approach (coughhacky-solutioncough) here and how we actually use it here

Figuring out how to get it to interact with the normalized cache is definitely a bigger challenge!

[bsara]

@sgrove I actually found your blog article while searching and looked through your code for a bit but couldn't find the solution that you had described in the article, so thank you for the link.

I've ended up doing a similar thing. We have redux in our app as well, so I created a custom link that just updates the redux store with the extensions for the query performed.

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, React Apollo feature requests are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to https://github.com/apollographql/apollo-feature-requests/issues/117.