DataTables - kill ajax requests when a new one has started

Question

I\'m using DataTables 1.10.15 in Server Side mode.

I\'m passing the contents of a form to a PHP script via ajax in order for it to search a database:

Answer 1

If you were using the search field that DataTable offers by default, you'd want to use the searchDelay option. By default it is set to 400ms when you use server-side processing. However, you have "searching": false, therefore you cannot use this option for your use-case.

You provide your own custom input element to perform searches. This is a perfectly valid use of DataTables. However, what you should do is not abort requests after they are created but prevent the creation of extraneous requests in the first place. What you should do is debounce your calls to myTable.draw() In the example below I'm using Lodash's debounce. You could use an implementation from another library if you want. In the following example, I've also modified the event handling to check whether the input field value has actually changed between keystrokes. You were checking for tabs but that's only the tip of the iceberg. Using arrow keys will also generate keyup events. Event just pressing and releasing the shift key will generate a keyup. The code below takes care of all those situations by checking whether the value of the field has changed since the last stroke and just ignore the event if there has been no change.

I type fast enough that if I type "I'm a little teapot" in the field presented in the example below I'm seeing "drawing" on the console only once.

// We create a new function that will debounce calls to the draw() function.
var debouncedDraw = _.debounce(function() {
  // myTable.draw();
  console.log("drawing");
}, 500);


var prev_value = undefined;

/* Handle Primary Search */
function processPrimarySearch() {
  var obj = $(this),
    search_id = obj.attr('id'), // e.g. #field1
    search_value = obj.val(); // e.g. '123-456'

  // There's been no change to the field, ignore.
  if (prev_value === search_value) {
    return;
  }
  prev_value = search_value;

  /* Wait until at least 3 characters have been entered, or user has cleared the input */
  if (search_value.length >= 3 || (!search_value)) {
    debouncedDraw();
  }
}

$('#primarySearch input[type="text"]').on("keyup", processPrimarySearch);

<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div id="primarySearch">
  <input type="text">
</div>

---

You asked in a comment if you should keep the code you had that aborts any previous Ajax query launched by DataTables when DataTables launches a new query. I would remove it. I've never relied on such code ever in my applications. (You mentioned my question. Yes, I do use the code in the answer I gave there but that's tear down code which is part of a test suite, not application code.) In theory it would seem like it is a good thing to do. After all, a new query makes the old ones obsolete so why not ditch the old queries and save some work? Right? In practice, the gains would be modest because:

1. At the speed humans interact with your GUI, chances are that by the time an abort() call is issued, the Ajax request will already have been sent out on the network. (I actually ran some manual tests, and indeed, I was never fast enough to prevent the browser from sending the request out.) So it means that the server will receive it even if you abort it.

2. Furthermore, abort() is not meant to notify the server that the request has been cancelled. So you won't save work on the part of your server. Look at this question for the issues. (Searching for "server" on the page will bring you right where people talk about the issue of whether the server is notified, and what to do if you need to notify the server that a request has been cancelled.)

You may be saving some redrawing time but that's not something I'd worry about until it is actually a problem.

On the other hand, aborting requests like this may cause other problems. For the sake of seeing what would happen, I modified one of my applications to abort old requests, and the whole thing immediately bombed. Aborting requests did not play well with the way I've set up DataTables. I don't know what exactly is causing the problem. Maybe I'm using just the right settings to get it to go boom. Or I'm using a plugin that does not like aborted requests. At any rate, aborting requests can cause problems.