Dynamic sorting (sort function that depends on dynamic data)

Dynamic sorting (sort function that depends on dynamic data)

mgalgsmgalgs Posts: 7Questions: 4Answers: 0
edited September 2016 in DataTables 1.10

(This is a cross-post from my question on StackOverflow. I didn't even think about posting it here until I had already posted it there... Sorry about that...)

I'm using the columns.render option to implement custom sorting for a table. That works fine when the logic within the sort function only depends on static data. However, I'd like to provide some controls to my users controlling how the sorting should happen. The problem is that it seems like DataTables is caching the first sort result, so when the user tries to change the sorting controls it doesn't have any effect on subsequent sorts.

In short, I'd like to have a dynamic sort function.

Obviously this is best explained with a test case, which you can find here. The idea is to allow the "Info" column to be sorted either by "customer name" or "price", depending on what the user selects in the radio above the table. Run it and you'll see that the sorting only works for the initial radio selection.

This question has an accepted answers - jump to answer

Answers

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

    Hi,

    Short answer: You are correct - DataTables does cache the value. Use the row().invalidate() method to tell DataTables to re-read from the data source whenever the values changes (or the more general rows().invalidate() which can be used to invalidate all rows in the table).

    Long answer (no support credits charged for this, its a "fun" thing to explain on a Saturday night when the kids are, finally, asleep :smile:):

    DataTables actually performs two levels of caching for the sorting data.:

    1) Per cell, as the column is requested for sorting. This is the data from your rendering function (or if no rendering function is used, just the original data). This cache is used so DataTables doesn't need to request data from the original data source for every sort operation. That would be horribly slow, particularly if a DOM operation is involved, such as reading the HTML cell, or in your case where a bit of jQuery is used in a renderer. Hence why the invalidate methods are provided, for exactly the situation you find yourself in - the cache is out of date relative to the data in the page.

    2) Per data point, as the data is sorted. This allow the pre formatter for custom (and built in) sort methods to be executed once and once only for each data point being sorted, per sort. Consider for example the case where you have a formatted date string and want to convert it to an integer for sorting - rather than executing the deformatter every time that data point is passed into the sorting function (it might only be once, it might be many times).

    The two caches used to be very distinct, but with 1.10 they have increasingly merged together, and probably will result in only a single cache level eventually. Regardless, the invalidate methods will still be the way to tell DataTables that there is new data for reading!

    Basically its all a tradeoff between performance and developer convenience (i.e. needing to call the invalidate method.

    Let me know how you get on with it.

    Regards,
    Allan

  • mgalgsmgalgs Posts: 7Questions: 4Answers: 0

    You, sir, are a hero! Worked like a charm.

    I've added an answer to my SO question giving a full working example, for any future DataTabler.

This discussion has been closed.