✊🏿 Black Lives Matter. Please consider donating to Black Girls Code today.
🧬 Learn how to build RNA-Seq data apps with Python & Dash. Register for the May 20 Webinar!

Unavoidable circular dependency when using backend paging and filtering with datatables - Feature request

I have played a lot with datatables and I ran into a simple, yet seemingly unsolvable issue when using backend paging and serving.

The architecture of my dash project is as follow:

  • I have a set of UI modules that define filters
  • I have a master function that fetches data from a database and applies the requested filters (and caches results)
  • I have a call back that uses the above + page_current attribute to serve the DataTable’s data and page_count.

The issue comes when the following situation arises:

  • A user scrolls through unfiltered data. Let’s says he goes up to page 10.
  • At that point the user applies a new filter, this filter means we don’t have 10 pages of data anymore, but only 3.
  • What happens here is that the users sees an empty table, because he is at page 10/3… !

(note that in this case, the user can still see “page 10/3” and go back to regular pages, but if we have page_count=1, the page navigation doesn’t even show up, so the user is stuck)

I tried to circumvent this issue by changing the page_current attribute from my callback in this type of situation… but this always leads to a circular callback. In fact, we have:
page_current-> displayed data -> page_count -> page_current

Do you know what type of architecture could work?

I would suggest the following feature:

  • if page_current>page_count, force page_current=page_count by changing page_current


yeah that’s a good idea. or perhaps we go back to page 1?

Indeed, going to page 1 (i.e. page_current = 0) would be great !

As a matter of fact, what I do now in that case, is to render page 1, which will at least show data even if the page number is wrong.