Add "reduxRootSelector" parameter to the ApolloClient contructor

[vovacodes]

This feature was discussed with @stubailo on the Slack channel

[stubailo]

For backwards compatibility, can we still accept a reduxRootKey option, and simply convert that into a function? It can also print a warning telling people to upgrade to the new option.

Perhaps we can remove the backcompat in 1.0.

[abhiaiyer91]

Would we be against having reduxRootKeyOrSelector where the user can optionally provide a selector function? I'm not sure how many users want to override the rootkey behavior with functions? Is this a lot?

[stubailo]

@abhiaiyer91 I was thinking it would be simpler to just have one way to pass it.

But I would be on board with a hybrid option. I think calling it reduxRootSelector is fine, since you can imagine that passing a string as the selector would just select that key.

[vovacodes]

@stubailo @abhiaiyer91 We cannot actually remove the reduxRootKey option, because in case client constructs the store by itself it needs to know where to put the state in, i.e. what key to use and unfortunately you cannot extract that information from the selector.

[jbaxleyiii]

@wizardzloy I'll need to update this in react-apollo as well

[stubailo]

in case client constructs the store by itself it needs to know where to put the state in

Is there any reason you would care what that key is called if you didn't create the store yourself? Since then Apollo is the only thing using that store.

[vovacodes]

@stubailo fair enough, if you don't see a scenario for that, I don't see it either. Let's then proceed with the reduxRootSelector option that can be either a string or a function, while preserving the reduxRootKey with a warning message. I'll implement the changes.

@jbaxleyiii sure, I'll open a PR to react-apollo once this one is merged, would it be ok?

[stubailo]

This looks great, we should merge it ASAP!

[vovacodes]

@stubailo I've updated the PR according to your comments

[stubailo]

Merging here: #662

[stubailo]

Done!