`__reload` function

RagnarGrootKoerkamp

I am using a modification of this (https://editor.datatables.net/examples/extensions/rowReorder.html
) example to rerender some data in the postRemove callback after the data has reloaded:

table.ajax.reload(/*callback*/, false);

Currently, it isn't working, because in the callback, the table.data() functions return the data in the state after deleting, but before updating the data.

I think the problem is in the __reload function (line 7505) in jquery.dataTables.js. There, the callback is set to fired once on the draw event. Is seems that the removal of a row fires the draw callback at some point after calling postRemove. Hence, the ajax callback is fired too soon in a different context.

In the case of an ajax callback, I think this would be solved by moving/copying the callback definition to just above the _fnReDraw call, or maybe just calling the callback explicitly after the redraw function.

Example

When I change the source code for the mentioned example to

        .on( 'postCreate postRemove', function () {
            // After create or edit, a number of other rows might have been effected -
            // so we need to reload the table, keeping the paging in the current position
            console.info('postRemove fired', table.column(0).data());
            table.ajax.reload( function(){
                console.info('callback fired', table.column(0).data());
            }, false );
            console.info('postRemove done', table.column(0).data());
        } )

All three callbacks show the same list of numbers, but I expect the callback fired to show the list of numbers after the reload has been completed.

Possible other ways to solve this:
- Use setTimeOut(function(){ table.ajax.reload(); }, 0);
- Send the new data for the table directly with the delete callback. (This required some private functions from Editor.php, and the returned rows must be handled separately on the client side, but it saves a callback.)

allan

Excellent question - this got the brain working in the morning!

This is the sequence of events as they happen:

1. Editor gets the Ajax response from the delete
2. It performs the delete
3. Triggers your callback
4. An Ajax request is sent off
5. Meanwhile, the code carries on and does the remove
6. Editor calls its commit which will do a draw
7. That is triggering the Ajax reload callback
8. The data from the Ajax call finally loads

So its the async nature of Ajax that is causing the issue.

This is assuming you only delete a single row. If you delete multiple - goodness knows what the exact sequence will be! One Ajax request for each row requested, so it will get very confusing.

I would very strongly recommend you don't use ajax.reload() in the postRemove event. Use it in submitComplete. At that point Editor has finished with all its drawing and updating of the table.

Another option is to use the draw option of form-options and set it to none so Editor doesn't redraw the table. But you'll still run into issues when deleting multiple rows.

So although I think the above code can be modified to not have this issue, I'll still take a look at how I can improve the callback so it only triggers on the Ajax load, and not just on the next draw.

Allan