3 ms·

This library is like a building block to e.g. building your own interactive table functionality. Let's say you have an HTML table, and you want to allow users t

This library is like a building block to e.g. building your own interactive table functionality. Let's say you have an HTML table, and you want to allow users to dynamically search or sort the table. Step 1 could be to translate the table to JSON, step 2 would be do all your JS magic on the JSON data set, and step 3 would be write it back to the table. This approach is cleaner than trying to do a bunch of logic on the DOM text. So, this plugin is step 1 done for you.

bdg 13y ago
I suppose that's my issue. Dynamically searching or sorting wouldn't require converting to JSON, I'd rather work with the existing table object: tableName.rows[rowNum].cells[cellNum] Instead of loading all of that into a variable (a second time, it's already an object on your page), trying to keep it in sync, binding events in both directions to keep it in sync, the load of doing twice the work, the lag of redrawing the entire table every time you want to do something, etc.. I don't see why this is cleaner than working on the DOM. I've done this a number of times and only found headaches when trying to build something larger than a silly toy or a list of 30 items on a table. IIRC DataTables did something like this internally last time I looked at it, and that thing konks out and either slows down your page or crashes the browser depending on how many cells you load into it.
- JangoSteve 13y ago
  I think the issue is that, if you are doing something like sorting, you actually are going to have to redraw the entire table. Also, for things like plain-text searching, it's faster to do it on a collection of objects detached from the DOM in JavaScript than to scan the DOM, and especially if you're doing non-text comparisons (like comparing a number with the parseFloat representation of the values in one of the table columns for all rows). And finally, if you are going to read and then redraw in the DOM, it's best to do it as grouped atomic operations due to the inefficiency making the browser reflow (https://developers.google.com/speed/articles/reflow https://developers.google.com/speed/articles/reflow). For what it's worth, this is how Dynatable works internally, though I haven't had any issues with it being slow, though it's possible I just haven't used it with large enough data sets yet (I've only used it on tables of probably 1000 rows or less so far).

bdg 13y ago

I suppose that's my issue. Dynamically searching or sorting wouldn't require converting to JSON, I'd rather work with the existing table object: tableName.rows[rowNum].cells[cellNum] Instead of loading all of that into a variable (a second time, it's already an object on your page), trying to keep it in sync, binding events in both directions to keep it in sync, the load of doing twice the work, the lag of redrawing the entire table every time you want to do something, etc.. I don't see why this is cleaner than working on the DOM. I've done this a number of times and only found headaches when trying to build something larger than a silly toy or a list of 30 items on a table. IIRC DataTables did something like this internally last time I looked at it, and that thing konks out and either slows down your page or crashes the browser depending on how many cells you load into it.

JangoSteve 13y ago
I think the issue is that, if you are doing something like sorting, you actually are going to have to redraw the entire table. Also, for things like plain-text searching, it's faster to do it on a collection of objects detached from the DOM in JavaScript than to scan the DOM, and especially if you're doing non-text comparisons (like comparing a number with the parseFloat representation of the values in one of the table columns for all rows). And finally, if you are going to read and then redraw in the DOM, it's best to do it as grouped atomic operations due to the inefficiency making the browser reflow (https://developers.google.com/speed/articles/reflow https://developers.google.com/speed/articles/reflow). For what it's worth, this is how Dynatable works internally, though I haven't had any issues with it being slow, though it's possible I just haven't used it with large enough data sets yet (I've only used it on tables of probably 1000 rows or less so far).