Client scoped query recyclers (#513)

[rcoedo]

This PR addresses the issue #513. I used a WeakMap as suggested in this conversation #462 (comment), but I'm not sure if we should polyfill WeakMap.

I tried the code linking the package to my playground and it works, but I'm a bit lost with the test structure of the project and I don't really know how to write a test for this feature.

Also I'm also quite new to Apollo and I've never touched Typescript before so I really appreciate all the feedback you can give 😄

[apollo-cla]

@rcoedo: 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/

[jbaxleyiii]

@rcoedo thank you for this PR! I'll take a look at it today and provide some feedback!

[jbaxleyiii]

@rcoedo the code for this looks great! I'll see if I can write up a test scenario for you with some guidance of how to test! 👍

[rcoedo]

Thanks for reviewing it @jbaxleyiii

I've been thinking about this isssue and having these WeakMaps all around as global application state seems kind of hackish. It works but I think there has to be a better solution.

Maybe a better approach would be to have a Map<Component, Recycler> in the ApolloProvider component and pass the recycler via context, so the thing would really be scoped by provider and not just by client (two providers using the same client wont share the recyclers). In fact, the whole thing could be a new RecyclerProvider that wraps the current ApolloProvider and handles that context.

any thoughts?

[jbaxleyiii]

@rcoedo I do think adding it to the context could be good, but I'm nervous about updating causing rerenders based on context updates. By keeping it out of the tree, we don't risk updates.

I'd rather not introduce new providers (at least to the external API). What would the updating look like? Could we write a test to ensure it wouldn't rerender?

I do think having it on the context would be great btw!

[rcoedo]

I think it wont cause rerenders since the context will only hold a reference to a Map and that reference will never change.

The provider I propose is internal only, since we don't want to leak the recycler implementation details. For safety, in that provider we could implement shouldComponentUpdate as a function that always return false.

[jbaxleyiii]

@rcoedo that sounds great! Would you update this PR to move to that version?

[rcoedo]

@jbaxleyiii I updated the PR. Current tests are passing and I manually tested it out in my playground and it seems to be working.

If you feel like we need more testing I'd really appreciate some guidance, there are a lot of use cases that I probably miss since I'm not experienced with apollo or react-apollo.

Thanks! 😄

[jbaxleyiii]

@rcoedo YAY! This is so great! I'm going to do a release to address some flow type issue then take a look this week! Thank you!!

[jbaxleyiii]

@rcoedo I think this is a great start. We can come back and increase testing later but I'm going to merge and release this 👍

[rcoedo]

@jbaxleyiii Thanks for the kind words 😄

I've been thinking and with this implementation the recyclers will be reset when the client changes in the ApolloProvider. I'm not sure how are users using this. Is it common to bounce from client to client in the same application? If this is the case, we may need to keep those recyclers alive as well, and use a Map<ApolloClient, Map<Component, QueryRecycler>> instead to store the state.