Apollo Link Context doesn't work on Apollo Client 2.5

[ralphchristianeclipse]

The context is empty on the resolvers for Apollo Client 2.5 local state management

Any workarounds?

[veeramarni]

Any update on this issue?

[ralphchristianeclipse]

Same any updates?

[veeramarni]

I have verified with 2.5 version, I see context is working.

    client.mutate({
      mutation: Save,
      variables: {
        resource,
        value: 'test',
        options: {},
      },
      context: {
        apolloClient: client,
      },
    });

In the resolver, i can see the context that i passed.

[ralphchristianeclipse]

I have verified with 2.5 version, I see context is working.

    client.mutate({
      mutation: Save,
      variables: {
        resource,
        value: 'test',
        options: {},
      },
      context: {
        apolloClient: client,
      },
    });

In the resolver, i can see the context that i passed.

But you have to manually pass the context.

I'm using vue-apollo it will probably work to modify the prototype of the apollo class .mutate function.

[barbieri]

Since the @client moved to be built-in and not a link anymore it created a different code path, while the Server executes through the link:

https://github.com/apollographql/apollo-client/blob/master/packages/apollo-client/src/core/QueryManager.ts#L1160

The client query completely ignores the context, calling runResolvers() directly:
https://github.com/apollographql/apollo-client/blob/master/packages/apollo-client/src/core/QueryManager.ts#L1170

I'll try to find out how to fix this

[ralphchristianeclipse]

This has been partially fixed using the defaultOptions which helps me removed apollo-link-state and apollo-link-context

but the problem is there is no way to set this up as a function.

  const defaultContext = {
    ctx,
    ...context,
    auth: window.owner
  };


  const client = new ApolloClient({
    cache,
    link: links,
    connectToDevTools: isDev,
    queryDeduplication: true,
    resolvers,
    // typeDefs,
    assumeImmutableResults: true,
    defaultOptions: {
      query: {
        context: defaultContext
      },
      watchQuery: {
        context: defaultContext
      },
      mutate: {
        context: defaultContext
      }
    }
  });

any thoughts?

[ralphchristianeclipse]

Another problem is the link pipeline doesn't seem to work with the local stage management

for example apollo-link-logger doesn't log anything when doing client queries

[barbieri]

Another problem is the link pipeline doesn't seem to work with the local stage management

for example apollo-link-logger doesn't log anything when doing client queries

the >=2.5 code has special case for @client that doesn't run the link, this is a problem because you can't get the context, you can't have your error handlers to run, you can't do all that you usually do with the usual link chain :-(

[ralphchristianeclipse]

@barbieri Thanks for that. maybe a hook or function that will run the link pipeline which would be optional for the dev to put in on the ApolloConfig

[barbieri]

@ralphchristianeclipse I'm not sure what motivated the specific handling, but in my experience it's worse than handling as link, you miss flexibility on how how to handle errors (ie: we use onError to append some to local state and show in the UI, we put the environment configuration in the context...)

[ralphchristianeclipse]

@barbieri this works initially on the defaultOptions but there are some parts that the context is not available. I hope this gets a simple solution.

[ralphchristianeclipse]

@barbieri

the resolution i've done is to wrap it in a function.

export const createContextResolver = resolver => {
  console.log(resolver);
  return (root, args, context, info) => {
    console.log(context);

    return resolver(
      root,
      args,
      { ...context, ...context.client.context },
      info
    );
  };
};

and then use it on my resolvers like this.

import { createContextResolver } from '../../utils/resolver';
const mapObject = (object, reducer) =>
  Object.fromEntries(Object.entries(object).map(reducer));
const mapValue = callback => ([key, value]) => [key, callback(value, key)];
const createContextResolvers = object =>
  mapObject(
    object,
    mapValue(value =>
      typeof value === 'object'
        ? mapObject(value, mapValue(value => createContextResolver(value)))
        : createContextResolver(value)
    )
  );
const resolvedTypes = createContextResolvers(types);
console.log(resolvedTypes);

and then on the client you just put up a context property there.

  const defaultContext = {
    ...ctx,
    ...context,
    auth: getAuth()
  };
 const client = new ApolloClient({ ...options })
 client.context = defaultContext;

[ralphchristianeclipse]

Or you can put it up as a function

export const createContextResolver = (resolver, key) => {
  console.log(resolver, key);
  return (root, args, context, info) => {
    const newContext = Object.assign(
      context,
      typeof context.client.context === 'function'
        ? context.client.context()
        : context.client.context
    );
    return resolver(root, args, newContext, info);
  };
};

and use it like this

 client.context = () => defaultContext;

[barbieri]

yeah, we use something like that, however we have a reducer to wrap all the resolver methods of a given object

[veeramarni]

I'm stuck as well, trying to find a better way to pass additional details to context so that they can be accessible in the resolver.

[veeramarni]

#4533 (comment)

@ralphchristianeclipse Is this a workaround still only the option to feed the context? I want to find a way to load the context after the apollo client initializes but not through the hooks for every query and mutation.

[hwillson]

A lot of the Apollo Client internals have changed since v3 was launched. We recommend trying a more modern version of @apollo/client. Let us know if you're still encountering this issue. Thanks!