Apollo-client: Polling endpoint

Created on 23 Apr 2016  路  9Comments  路  Source: apollographql/apollo-client

Simple implementation could just be polling interval.

Let's discuss API design!

@stubailo

Most helpful comment

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?

All 9 comments

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jamesreggio picture jamesreggio  路  3Comments

helfer picture helfer  路  3Comments

gregorskii picture gregorskii  路  3Comments

MichaelDeBoey picture MichaelDeBoey  路  3Comments

kriswep picture kriswep  路  3Comments