gistfile1.md

In our application, we have a need to wrap Apollo Client, amongst other reasons we do this to pass default link context to operations. This works well for operations originating from the top-level APIs, but it doesn't for the subscribeToMore function that gets created by useQuery.

We could augment useQuery further and also wrap each subscribeToMore function object that's created, but it struck us that the relationship between the useQuery invocation and the created subscribeToMore function might actually imply that it should inherit the link context of the useQuery invocation. Below you can find a naive patch that does this.

// src/core/ObservableQuery.ts  

public subscribeToMore< 
      TSubscriptionData = TData, 
      TSubscriptionVariables = TVariables 
    >( 
      options: SubscribeToMoreOptions< 
        TData, 
        TSubscriptionVariables, 
        TSubscriptionData 
      >, 
    ) { 
      const subscription = this.queryManager 
        .startGraphQLSubscription({ 
          query: options.document, 
          variables: options.variables, 
-        context: options.context, 
+        context: options.context || _this.options.context, 
        }) 

We would be happy to create a proper PR for this, but before doing so we have a few questions:

1. Is our intuition correct that, due to the relationship between useQuery and subscribeToMore, it makes sense to inherit the context?
2. We did not have any location in our [large] codebase that needed to provide any further customization to the context for the subscription, so the choice of how to pass the context along was made somewhat in the dark. The reason we went with OR instead of merging the inherited context and options.context was that we figured it would allow for total control; and it doesn't seem too unreasonable that when somebody would pass context to useQuery they have access to that same context in the scope where they would invoke subscribeToMore. Do you have any opinions on this?

great job.