AJAX + pager + customAjaxUrl

[devnuhl]

I have seen others post about this, and their issues have been resolved by updating. Ours seems to happen regularly, though, whenever we try to update. 2.10.7 is fine, but I have tried 2.15.4-5 as mentioned in another issue's resolution, and we were running 2.17.8 when we noticed one of our subsystems stopped working properly. I forget the last version we tried updating to when this issue occurred.

With the updated versions, it seems that only the first time we change our ajax url that it works. Any time after the initial load, and first change, it simply does not alter the url, and does not appear to call the function defined in customAjaxUrl, based on console logging.

Any time we click one of the items on our sidebar, it changes the filter string, which we place in the url to filter based on the specific criteria. But it does not seem to want to work more than once, and it did previously. I haven't found anything in the changelog that would indicate a change responsible for this. I may just be missing something simple, but I can't see it. Snippets below.

customAjaxUrl: function (table, url) {
                url += "&" + tableURLFilterStr + '&statuses=' + JSON.stringify(statusFilters);
                //$(table).trigger('update');
                // send the server the current page
                return url;
            },

function changeTableFetchFilter(filter) {
    $.cookie('currentFilter', filter);

    if (filter != null) {
        tableURLFilterStr = "&filterID=" + filter;
    } else {
        tableURLFilterStr = tableURLFilterStr + '&rand=' + Math.random();
    }

    $('#ticketListTable')
        //.trigger('changingUrl', tableAjaxURL + tableURLFilterStr)
        .trigger('update');
    fetchSidebarMenuItems(true);
}

[devnuhl]

there is a xhr request that follows, but not as a result of the update trigger. it only comes from the fetch below that. Do we need to do something additional to get it to update?

[devnuhl]

I've gotten as far as determining that the ajaxUrl is being updated in the pager, based on the event contents when the update is triggered. However, despite the ajaxUrl changing, it is not actually sending a new request to the server.

[Mottie]

Hi @devnuhl!

There is a built-in check to make sure that multiple calls are not made if the current page, filter, page size, total rows and sort has not changed.

To bypass this, set table.config.pager.last.sortList = null; to clear out the last sort and thus allow the process to continue and make the ajax call.

I know this isn't ideal. I am open to suggestions.... maybe I should compare the ajax URL as well?

[devnuhl]

I think checking the ajaxUrl would not be a bad idea, especially with the customAjaxUrl parameter being able to alter and send a different url to the server. The ajaxUrl as I saw from putting a listener on the update event shows that the two parameters we throw at the end were indeed changing, but the table was not being updated. For now, though, we can probably adjust the sortList as suggested and see if that fixes the issue.

[devnuhl]

the sortList = null does work for our setup. Though if we have a mechanism that allows us to alter the url, we should probably check if it has changed before preventing the request. It is especially hard to debug. I thought that might be the case, but I was having trouble tracking down the logic in the source for it that would let me see what it was comparing.

Thanks for the help.

[Mottie]

Here is the code in the pager addon (lines 628-631); the code is essentially the same for the pager widget (of course the line numbers are different).

I'm not sure why setting the sortList tonull isn't working. I'll look at it more in depth when I finish my current work on a different part of this project.

[devnuhl]

My last post might have been misread. Using your suggestion of sortList = null /does/ work for us. Everything after that was commenting on your idea of comparing the ajaxUrl as a better possible solution in the future. Sorry if it was confusing. sortList = null => 👍

[Mottie]

Oh sweet! I'll try to get working on that soon 😺

[Mottie]

Hi @devnuhl!

I've included an ajax url check in the pager code within the working branch. Please test this change and see if it works for you as expected.

[devnuhl]

Dropped in the working branch code, loaded everything up (after commenting out the config.pager fix), and it's still not updating when we change the url. At this point I want to go for some clarification, the return url; from the example for customAjaxUrl actually does update the ajaxUrl, correct?

It says that it returns that to the server, but I want to make sure I'm not missing some explicit change I should be making that is not as explicit as necessary before I write this off as not working correctly. I looked at the commit and that's what prompted the clarification question.

Also noticing that with the config.pager fix, every time the table updates, it returns to the first page of the table, which is rather problematic when we're using the table. I have not tested setting it to null and then back to its original value, but only because I imagine by the time we trigger the update, it will still appear as nothing has changed. Am I correct that this is what caused that unexpected behavior?

[devnuhl]

Still not seeing how resetting the last sortList being cleared is resetting the page. The page value should not be changing, and yet, no matter what page I'm on, 0-3 for pages 1-4, it goes back to 0 when it updates the table.

[Mottie]

The return url; is required if the customAjaxUrl is defined. This callback is executed after all other changes to the url have been made. So it is the last function that touches the url.

I'm not sure why the pager is going back to the first page.

• Is the p.page variable being changed?
• Did you set the pageReset option to false?
• Or is the pageSet method being used?

Also, check out this demo which uses filltext.com to provide JSON data to build the table; the sorting and filtering functions don't work (not available from filltext.com), but if you watch the development tools network tab, you'll see the changes in the url.

[devnuhl]

We aren't setting it to false, it may be something that was added in the period between our updates and been missed when I went through the massive changelogs. I still hadn't had a chance to setup a test environment to track back where it might've changed. So for now, I'll assume it has to do with the pageReset being involved and not false. Will update the separate issue I filed if I find more information.

Right now that seems like it might be the issue. For now, removing that one line made everything work while implementing the config.pager.last.sortList = null; fix. The ajaxUrl check did not work for me, but that might've been that I was modifying the url after the check happened, since customAjaxUrl sounds like it would be after the check, and I need to actually modify the url before the update is triggered. That might be where the problem is for that fix. Will try to get some testing in today and update. Concurrent work on different feature additions in multiple branches is a headache when needing to test specific changes, apparently.

I shall return!

[devnuhl]

Initial tests look like when I change the ajaxUrl directly, things work better. And I'm not sure if the fix was applied during that test or not. Something else has come up, though, and I need to sideline this for the time being. Will hopefully have some more time this afternoon for it.