Skip to content


Subversion checkout URL

You can clone with
Download ZIP


data-sorter="false" should bypass parser detection loop #629

thoughtafter opened this Issue · 4 comments

2 participants


data-sorter=false should bypass the detection loop. In big tables this loop is a performance issue. I think the problem code is here (only cursory examination):

Line 242 jquery.tablesorter.js

p = ts.getParserById( ts.getData(h, ch, 'sorter') );
// empty cells behaviour - keeping emptyToBottom for backwards compatibility
c.empties[i] = ts.getData(h, ch, 'empty') || c.emptyTo || (c.emptyToBottom ? 'bottom' : 'top' );
// text strings behaviour in numerical sorts
c.strings[i] = ts.getData(h, ch, 'string') || c.stringTo || 'max';
if (!p) {
    p = detectParserForColumn(table, rows, -1, i);

If data-sorter=false p is false which then calls detectParserForColumn. If data-sorter is deliberately set to false this loop should be skipped because the user is asking for no sorting.


Hi @thoughtafter!

The parser type is still detected because in some cases a filter widget will need parsed data from a non-sortable column. For example, this would be true for dates within a column which need to be parsed in order to properly apply operators like >, >=, < and <=.

The parser detection code shared above is only executed at table initialization and when an update is triggered ("addRows", "update", "updateAll" and "updateCache").

@Mottie Mottie added the How To... label

Thank you for the prompt reply.

It my current use cases, for all columns with data-sorter=false I also have data-filter=false. So this request could be changed to: avoid detectParserForColumn if both of these conditions are in place. Or, alternatively if some other mechanism could be used to skip the detection that would be fine too. Thank you.


Sure, I could add this sort of enhancement. Let me do a little testing to make sure it won't cause any problems.

@Mottie Mottie added the Enhancement label

It makes sense that the code within the core shouldn't be written to make exceptions for widgets. So, the solution I came up with was to add a new parser-false setting. It can be added as follows:

  • A data-attribute (data-parser="false")
  • metadata (class="{ parser: "false" }")
  • A header option (headers : { 0 : { parser: "false" } })
  • or, as a class name to the header (class="parser-false")

This change is now available in the working branch; and I do plan on pushing out the next update by this weekend.

@Mottie Mottie added the Next Update label
@Mottie Mottie closed this in 26db918
@Mottie Mottie removed the Next Update label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.