Simple implementation could just be polling interval.
Let's discuss API design!
@stubailo
Idea: it could be beneficial to poll just part of a query, depending on how big your queries are.
Idea: you could have your polling query independent of your component query to update certain parts of the cache
We could have the base polling method on the client itself, then expose the API to the react-apollo. If it gets added as an argument to watch query it would be one in the same
Also along this, do we expose the handle as this inside a onResult method? If we did setting up things like cancel after a certain number of polls would be trivial to implement. If we don't, I'd like to add that
We could have the base polling method on the client itself, then expose the API to the react-apollo.
Definitely for this 100%!
do we expose the handle as this inside a onResult method?
Negative, I think we should avoid using this in our API at all costs (it means people who use arrow functions won't be able to access it, and I'd rather not get into the business of teaching people about the difference). Perhaps we can just pass it as a second argument?
const queryObservable = client.watchQuery({
query: `
query getCategory($categoryId: Int!) {
category(id: $categoryId) {
name
color
}
}
`,
variables: {
categoryId: 5,
},
forceFetch: false,
returnPartialData: true,
pollInterval: 1000, // ms to poll
});
const subscription = queryObservable.subscribe({
next: (graphQLResult, done) => {
const { errors, data } = graphQLResult;
if (data) {
console.log('got data', data);
}
if (errors) {
console.log('got some GraphQL execution errors', errors);
}
done() // stop watching the query OR just stop polling?
},
error: (error, done) => {
console.log('there was an error sending the query', error);
done() // stop watching the query OR just stop polling?
}
});
I think adding the interval to the object is the easiest entry point. The question is should the second argument of the observer functions stop the subscription (what I would expect) or just stop polling (confusing if you aren't polling). If it stops the entire query subscription, will we still need a way to stop the polling on its own?
I think it's ok if you sometimes need to tear down the query and start it again to do certain things? In most cases we should be able to make that synchronous if the data is already in the store.
@stubailo I did this on the flight out. I'll push it up as soon as I can (just landed). I didn't find the second argument needed BTW so the only change is adding pollInterval
Final design for first run:
const handle = client.watchQuery({
query: `
query getCategory($categoryId: Int!) {
category(id: $categoryId) {
name
color
}
}
`,
variables: {
categoryId: 5,
},
forceFetch: false,
returnPartialData: true,
pollInterval: 1000, // ms to poll
});
// extra methods
const subscription = handle.subscribe();
subscription.stopPolling();
subscription.startPolling(100);
Merged, and released as 0.2.0!
Most helpful comment
Definitely for this 100%!
Negative, I think we should avoid using
thisin our API at all costs (it means people who use arrow functions won't be able to access it, and I'd rather not get into the business of teaching people about the difference). Perhaps we can just pass it as a second argument?