RowReorder & Editor pull data twice when serverSide: true

RowReorder & Editor pull data twice when serverSide: true

FlashdownFlashdown Posts: 20Questions: 3Answers: 0

If you add a serverSide: true option to this example https://editor.datatables.net/examples/extensions/rowReorder.html
you will see 3 HTTP requests after reordering rows:
1. a POST request with the new row order
2. a GET request with draw=2 for fetching data
3. the same GET request but with draw=3

I found a way to get rid of the third request by setting drawType: none

       rowReorder: {
            dataSrc: 'sort_order',
            editor: editor,
            formOptions: {
                drawType: 'none'
            }
        },

But how to get rid of the second request? It does not make any sense to pull data from the server after rows are reordered since it won't make any difference.
And is the 2 duplicate GET requests just a bug or there's any sense in that?

Answers

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    When you are using server-side processing then any draw on the client-side will always make a request to the server to get the data to draw. In this case number 2 is coming from RowReorder which does a draw on the table to make sure everything is correctly shown for the new order.

    I fully agree that the Editor response should include the JSON data needed for the draw with server-side processing, but I'm afraid it doesn't yet have that ability.

    Allan

  • FlashdownFlashdown Posts: 20Questions: 3Answers: 0

    Thanks for the clarification, however, the two exactly the same GET requests still look like a bug.
    And maybe it would be possible to make the RowReorder extension not to call the draw method if the drawType: 'none' option is passed? Response from Editor already includes all the changed rows so any subsequent requests are just redundant.

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    Agreed - the two aren't quite playing together properly there. I've logged a bug for that in our internal tracker.

    Thanks,
    Allan

This discussion has been closed.