Whenever you’re working with third-party APIs, and you’re doing so in an asynchronous nature, there is always the chance that whatever it is you’re requesting is going to return a un-desirable result.

Perhaps it’s an error code, perhaps it’s a warning, or maybe it’s a simple message saying something like “We’re still processing your request on our end.”

In each case, you can usually handle them on the server-side just fine and let the client-side know how to handle it. But if you’re dealing with the latter case, that is where you’re blocked by the third-party processing; there are other things you can do to handle this situation better.

For example, in the latter case, it’s better to wait for a little bit then make the request again to see if the API has a different response for you.

But when doing this, it requires Ajax which obviously requires JavaScript. One of the obvious, yet more dated methods of doing this is to use setInterval.

The problem with this, though, is that it creates a stack of requests and then, as the response is ready, each item in the stack will get the same response.

This can drastically impact any given server. And there are better ways to go about doing this.

Properly Working with Ajax Requests

As per usual, since WordPress ships with jQuery, I’ll be using that; however, I also urge you – if you haven’t already – to look at Ajax in ES6 to get an idea as to how to do this natively.

Properly Working with Ajax Requests: MDN

Anyway, the idea is this: Rather than setting up some interval, then use the built-in Ajax functions to evaluate the response properly. And only under certain conditions, trigger the function again.

Case in point: jQuery’s $.post method offers some functions that can be used for exactly this. For example, it offers methods like:

  • done()
  • fail()
  • always()

And each of these is meant to be run under certain conditions of which I’ll show in some code samples momentarily.

Properly Working with Ajax Requests: jQuery.post

Before doing that, though, it’s important to understand that there are several parameters that I’m sending that I assume you’re familiar with:

  • the WordPress Ajax URL (which I’ll define as acme.ajax_url),
  • a URL to the post we’re viewing (which will be stored in a sUrl variable),
  • and a security nonce that I’ll be calling acme.security

If any of the above isn’t clear, please read the linked pages to see how this is achieved.

But with that said, here’s the idea behind how you can manage repeated Ajax responses without setInterval.

1. A Function for the Work

The first thing that you need to do is wrap the work you’re going to do in its own function. This means that you’re able to call it from anywhere else in the client-side application or even within the context of a timer (if absolutely needed).

For example:

And, as you can see, I’ve gone ahead and stubbed out some of the functions I mentioned above.

2. Handle the Success

In the case of the success, you can use an anonymous function as the callback for the $.post function. The primary argument with which you should be concerned is the response argument.

Typically, I like my response’s to have a success attribute and a failure attribute. This makes it easier to handle a case whenever the response completely successfully but the data that came back from the server wasn’t what I was expecting.

This doesn’t necessarily mean there was a failure. It just means that whatever I was looking to retrieve wasn’t found.

3. Handle the Failure

On the flipside, there are times in which something may fail. Why this happens can be for any number of reasons and to understand it properly, it’s worth inspecting the arguments the callback provides, namely the status and the error.

I can’t give concrete examples here because each API is different; however, I recommend at least writing data out to the console so that you can understand what’s going on and how you can gracefully handle it at a code level.

4. Handle the Unconditional Case

In this particular case, this function will fire regardless of if something was successful or not.

This function isn’t something that you may always need (no pun intended), but it’s a solid option for, say, hiding a progress bar or displaying something on the UI. This can give the user a bit of feedback that the request has completed its work (again, regardless of failure or success).

5. Handle the Success, Again

Finally, the done method is much like the success method but think of it as being intended to be called a second time.

That means that after the response has come back from the server with the response argument, the same thing will fire again once everything else has completed.

This gives you another chance to do anything you want to do with the response argument one more time before everything has completed.

I rarely use this, but there have been times where I’ve wanted to remove an element only after something was done, all other processing was done, and the response was successful.

Maybe You Don’t Need It All

Obviously, much of the code above is just for a demo on how to handle requests. But the purpose is to show how to handle said request without needing to set intervals to stack requests. Instead, you take advantage of pre-existing functions to, say, call the function again if there’s an error.

Anyway, this may be overkill for some, but for others who are used to using setInterval, it may be a much better way to manage Ajax requests that don’t stack up and fire the same request to the server when a response has already been managed.

And ultimately, that’s the goal: Efficient code that retrieves the information we need without bogging down the third-party API or our own user’s browser.

, ,