Possible new features (beforetablesort, initial & default sorting) about stupid-table-plugin HOT 2 CLOSED

Thanks for the ideas!

1. I don't see a need for a sorting class since we already know things are sortable by the data-sort attribute. th[data-sort]. I do like the asc and desc classes idea though.

2. I really, really don't want any more nested objects/blocks unless absolutely necessary. The plugin call is already a bit cumbersome as is when it comes to syntax. If we find a need for another parameter, we can cross that bridge when we get there.

3. Before table sort sounds great.

4. See #35

I really appreciate all the work you've put into this project :)

On Dec 11, 2012, at 7:23 AM, Scott [email protected] wrote:

A few minor things that could be useful.

Adding classes to the table headers when sorted. Obviously this is doable using the aftertablesort callback, but to me it feels like it should be in core. Potential names: sorting for columns that are able to be sorted, then sorting-asc or sorting-desc when sorting in the respective direction.

Move custom data types to a sub-parameter: i.e. instead of passing in { "date": function(){}, ... } to the plugin, do { "types": { "date": function(){}, ... } } instead. Currently we can't pass any other parameters into the plugin because they are parsed as data types.

A beforetablesort callback. One thing this could be used for is to display a message during sorting - if you have a very long table it can take a couple seconds for the sorting and redraw. The developer can then use the aftertablesort callback to remove the message.

Initial sorting: pass a column index into the plugin to sort by that column on load. You can set up the table HTML to be in the correct order initially (and most people do), but then anything you do in the aftertablesort callback is not loaded - e.g. custom sorting headers/classes.

Let me know what you think. I'm conscious that we don't want to bloat the plugin if the functionality is not necessary or won't be used by many people. But these were the features that came to my mind first.

—
Reply to this email directly or view it on GitHub.

from stupid-table-plugin.

The main reason for the sorting class is because targeting a class selector in CSS is more efficient than [data-sort], and has better browser support. However, it is getting towards micro-optimisation level and now that I think about it, probably adding the class to the HTML directly is better than dynamically adding via Javascript. 90% of users will be fine to target [data-sort] if they need it.

Re parameters: fair enough, main reason I suggested it was because of point 4. But your answer in #35 is good enough for me.

from stupid-table-plugin.