Extend ApolloProvider and graphql API to support multiple clients.

[1st8]

Related discussion: #464
Documentation PR: https://github.com/apollographql/react-docs/pull/163

TODO:

• If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass
• Update CHANGELOG.md with your change
• If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

[apollo-cla]

@1st8: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[calebmer]

I’m still opposed to this design 😣

1. It is a feature that assume a certain use case instead of a general feature that gives users the highest power to do what they want.
2. use is static.
3. It complicates ApolloProviders alternate usage as a Redux context provider.
4. It is challenging to maintain and extend by adding new features which also require plucking the client off of context.

I’m more interested in providing the basic tools to make this implementation possible and have specific use/as semantics implemented outside of react-apollo in a user’s codebase or in a community maintained package.

It’s unfortunate that we had to remove the prop behavior in the past because of prop naming collisions (see commit: 626dbb7), so instead of reintroducing that we should add client to the options function which can be computed from props. Such a design may look like so:

graphql(query, {
  options: props => ({ client: ... }),
})(MyComponent)

If a client does not exist, or it is null then we use the client from context. This is the minimum we can add to enable the maximum number of use cases including enabling you to build this functionality into a community maintained package.

Thoughts?

[jbaxleyiii]

@calebmer I'm good with the options version

[helfer]

I'd be okay with the options way that @calebmer proposed.

[1st8]

I won't be preparing a new PR in the near future (vacation coming up 🎉 ).
Changing this one doesn't make sense as well.
Still think that I don't want any clients in my props, but maybe thats just me.

Thanks for your time and feedback, I am gonna go ahead and close this.

[flexzuu]

Hey I implemented changes proposed by @calebmer. Currently i can't get the test-setup to work. #717
But my integration-test in a simple create-react-app is working fine. I will open a new PR linking to this one and #464 once the testing issue is resolved. Will add a PR to document the feature aswell.
PR is now Open: #729