add generic types to apollo client for Query and Mutation

[brettjurgens]

Fixes #777

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
• Add your name and email to the AUTHORS file (optional)
• If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

[helfer]

@kamilkisiela do you have a moment to review this PR? I'm asking since you initially had the idea for #777

[kamilkisiela]

@helfer I don't get the idea. Why we specify those types while creating an instance of ApolloClient?

ApolloClient<QueryType, MutationType>

and

public watchQuery(...): ObservableQuery<QueryType, MutationType>

With this approach, every watchQuery() will return an object of the same type, even if each query looks differently.

My idea was to specify generic type for each individual watchQuery, query and mutate methods.

For example:

apollo.watchQuery<Entry[]>({query: feedQuery});
// returns { data: Entry[], loading: boolean, ... }

apollo.watchQuery<Entry>({query: entryQuery, variables: { id: 2 }});
// returns { data: Entry, loading: boolean, ... }

[brettjurgens]

@kamilkisiela is this more what you're looking for?

[kamilkisiela]

This is be a breaking change if it comes to TypeScript based projects.

Right now we use it like this:

apollo.watchQuery({ query });

It will cause a warning about a missing generic type, so it's up to you guys if you want to release it in v0.5.X.

[brettjurgens]

unfortunately, generics cannot be made optional (there's an issue here: microsoft/TypeScript#2175), so yes, it will be a breaking change, but quite an easy one to fix (just add <any>)

[kamilkisiela]

@brettjurgens Yes yes, it's not that I see it as a big problem, it's just a breaking change that will screw up few projects if we will push it as 0.5.X. With 0.6.0 we can mark it as a Breaking Change to inform people and even with a release candidate, they can be prepared for it.

[brettjurgens]

agreed, should not be released in a patch version. 0.6.0 makes sense

[stubailo]

This update sure would go well with working TypeScript code gen: apollographql/apollo-tooling#5

[brettjurgens]

@stubailo FWIW there's also https://github.com/avantcredit/gql2ts

[helfer]

@brettjurgens Sorry I did't get around to doing anything with this PR until now! Do you think you could you change the base of this PR to zero-decimal-six and resolve all the conflicts in the next few days? If so, then we can merge it and release it with version 0.6. Otherwise I think we should probably close the PR and open a new one down the road, because it will only get harder to merge the PR as it gets more out of date with the rest of the code.

[kamilkisiela]

@brettjurgens yes, it would be super cool. I could make changes also in angular2-apollo in just one release.

[brettjurgens]

cool, will rebase on 0.6 right now

[brettjurgens]

@helfer just rebased it and the diff between this branch and the zero-decimal-six one looks clean

[brettjurgens]

@helfer tests are passing now, seems i missed a conflict or two when the base changed. should be all good now

[helfer]

@brettjurgens wonderful, thanks for your efforts! It always feels great to merge the oldest PR 😌