ABC of Polling in JS

No, not that kind of polling you silly! The JavaScript type, meaning repeatedly calling a given function in some interval of time. Sounds easy? Well, I hate to spoil a good day for you.

You don't want Tennet to happen in your code

One might think "What's the big deal here? Just use setInterval!". Not so fast bucko!

function callMe() {
  // sync stuff
  console.log('Aye there!')
}

setInterval(callMe, 1000)

// logs
// [0:01] Aye there! 
// [0:02] Aye there! 
// [0:03] Aye there! 

That may look fine for polling a synchronous function. Add a side effect making it asynchronous and we have a completely different story here. An async function may yield its results in a time that is longer than the polling interval.

let calls = 0
async function callMe() {
  calls++
  const callNo = calls
  // async stuff
  console.log(`Call #${callNo}`)
}

setInterval(callMe, 1000)

// logs
// [0:01] Call #1
// [0:03] Call #3
// [0:05] Call #2
// [0:08] Call #4

This is a mess that may lead to some serious errors in your code. We don't have constant time interval between the results. What's more important, the chronology is all screwed up! Chris Nolan would be happy, but we are not!

To get the calls in the right order we need to:

• make a call
• wait for the function to return something
• wait the defined delay time
• go back to the start

Getting the stuff

Getting the data back can be a bit tricky. In most cases, that polled function returns something interesting. To retrieve this data we need a callback function. We can also attach an event, to allow many callbacks. That is useful, as we may like to stop polling when certain response arrives and conditions are met. Or to feed some other logic with those responses.

Err... what?

Polling can be prone to errors. Especially when we call a function that calls some API on a remote server. Network errors or glitches on the server side may lead to rejecting some of that calls. Yet sometimes we would like to continue polling regardless of errors. Maybe that consequent call will return real and valid data. We should be able to stop polling only when a certain number of failures in a row takes place.

Pollinator to the rescue 🐝

I wrote a small, but busy little module you can use to address all those issues and more. Yes, we can be lazy again! Biggest advantages:

• very tiny, only 907B (that's right, bytes) minified and gzipped
• you can start, stop and pause anytime you want
• can stop polling when meting a condition based on current and previous returned data
• event based
• handles errors like a champ with configurable number of safe retries
• written in TS!
• Node and browser compatible

If you see a place for it, give it a try! Hope it saves some effort for you.

BTW Feedback is more than welcome!