DeferLoading not behaving

effkay

I'm experiencing issues with the deferLoading-option and Ajax. First, my init-code:

    var datatable = $('#table').dataTable({
        ajax: {
            url: 'my/url/'
        },
        columns: [
            { data: 'firstname' },
            { data: 'lastname' },
            { data: 'ip', type: 'ip' },
            { data: 'button', orderable: false}
        ],
        order: [[0, 'asc'], [1, 'asc'], [2, 'asc']],
        deferLoading: 0,
        processing: true
    });

My table is initially drawn with a set of rows. With deferLoading set to 0, these rows are preserved on pageload. However, because I set this option, I'm also expecting datatables NOT to call the ajax-url on pageload (at least this is what the docs indicate). But a request is still sent to the url and the response content is merged into the existing dataset, doubling everything up. I can't imagine this is how it's supposed to work. Or is it? Am I doing something wrong?

Note: I also tried setting deferLoading to different values, but I got the same result.

Any pointers would be appreciated immensely.
Thank you.

sliekens

I ran into the same problem. I guess that deferLoading was only designed to work with the serverSide option enabled. I agree it should work with client-side processing as well.

I opened a question about it but I think my question was too confusing because it has no answers: https://datatables.net/forums/discussion/38948/dom-data-source-client-side-processing-ajax-updates#latest

allan

This is correct - deferLoading is really only designed to work with serverSide.

Allan

sliekens

That's unfortunate because the reason why deferLoading exist is equally useful for client-side tables.

this option exists to allow you to instruct DataTables to not make that initial request, rather it will use the data already on the page

My application has a table that is pre-rendered on the server. The first page load returns a complete HTML document that does not need to be post-processed by client script. It contains a table tag that contains all the rows from the database.

When that pre-rendered data goes stale, it needs to be reloaded from the server. Rather than refreshing the entire page, we would just call ajax.reload().

The problem that we ran into is that when ajax is configured, the table always makes an initial request and merges the response data with the pre-rendered data. We do not want this, but we also do not want to convert our table to a server-side table and lose the benefits of client-side sorting/filtering/paging.

It would really be very useful if deferLoading would stop that initial request from happening, no matter whether the table is a client-side or server-side table.

effkay

I guess that deferLoading was only designed to work with the serverSide option enabled

Well, that's just silly. That basically leaves us with two options, neither of which are very palatable:

• Sacrifice client-side processing to get rid of the ajax-call, which IMO is a pretty bad compromise.
• Work around the initial ajax-call in some butt-ugly way.

I really wish there was a simpler option for this. Either that deferLoading works for serverSide = false or an explicit option:

{ajax: { initialCall: false }} // default true

tangerine

The docs are pretty clear on deferLoading:

Note that this option only has effect when serverSide is enabled. It does not have any effect when using client-side processing.

effkay

Sure the documentation is good on this. I read the docs, but my brain didn't make the connection that deferLoading wasn't working as expected because of the serverSide option, so my bad.

I would argue, however, that there really should be a mechanism by which we can disable the initial ajax-call, even if we aren't using server-side processing. As it is, this omission makes it a lot harder than it has to be to implement DataTables in an ajax-context.

allan

I agree - this would be a useful addition in a future version of DataTables. At the moment there is a significant backlog so I'm not likely to be able to implement it soon, but I have added it to my list.

Allan

effkay

Thanks, Allan. Glad to see that you are so open to suggestions. Keep up the wonderful work!