Сортировка и отбор данных в браузере
 

Примерно год назад начал работу над скриптом JS, который назвал Simple Table Sorter. Он должен был быть маленьким (200-300 строк), понятным и быстрым. Как я узнал позже, по лаконичности ему оказалось очень далеко до TinyTable Лейгебера (leigeber.com/2009/03/table-sorter/), но скорость он показывал вполне приемлемую, не хуже jquery.tablesorter.js (jSorter).

Мне хотелось добиться от скрипта большего, чем умеет jSorter. Например, изначально заложить возможность сохранения и восстановления состояния отсортированной таблицы или добавить в заголовок поля ввода для фильтрации данных. Пользователи, тестировавшие скрипт, также подстрекали к различным усовершенствованиям. Всё это привело к тому, что скрипт перерос в размере jSorter, и к версии 2.1 пришлось переименовать его в Big Table Sorter.

Большой размер получился, главным образом, оттого что я пытался учесть разные варианты решений, и многие решения оставил в двух вариантах – потому что так и не смог решить, что лучше:

1. Использовать при отрисовке таблицы innerHTML или appendChild?
2. Использовать картинки для стрелок, или рисовать стрелки на CSS (идею позаимствовал из SortTable.1.5.1.zip Ильи Лебедева – debugger.ru/blog/bystraja_sortirovka_tablic)?
3. Делать ли таблицу полосатой («зебра»)?
4. Разбивать ли на страницы (paginate)?
5. Добавлять поля отбора всем заголовочным ячейкам, или только тем, у которых явно назначен тип сортировки?
6. Давать ли возможность пользователям самим определять тип сортировки (удерживая при щелчке Shift или Control)?
7. Заставлять ли разработчика явно обозначать элементы thead и tbody?

И ещё множество более мелких вопросов. Некоторые волевые решения, конечно, всё равно принимать пришлось. Например, оставить такую удобную вещь, как «подсветка» строк при наведении мыши чисто на CSS (:hover), то есть лишить этой удобной вещи пользователей Интернет Эксплорера (IE). Потому что все варианты «псевдо-hover'ов» страшно IE тормозили.

Позже обнаружилось, что фатальный тормоз в IE возникал, в частности от использования table-layout: fixed (который вообще-то в нормальных браузерах используется для ускорения загрузки больших таблиц!). Но к этому времени желание патчить скрипт под недобраузер полностью было убито кучей мелких пакостей и недоработок MS – типа невозможности перезаписать innerHTML у таблицы или наличия значения по умолчанию display: block у элемента tr.

Результат работы

Протестировать работу скрипта можно на следующих примерах:

1. ir2.ru/test-tracker/limit202.htm – таблица в 200 строк, для старых компьютеров.
2. ir2.ru/test-tracker/limit1003.htm – таблица в 1000 строк.
3. ir2.ru/test-tracker/tracker2.php.htm – таблица в 500 строк, но из-за объёма текстов (500 KB) гораздо более неудобная для обработки, чем предыдущая.
4. Для сравнения подключил к последнему большому файлу jSorter (ir2.ru/test-tracker/tracker.php.htm) и TinyTableV3 (ir2.ru/test-tracker/tracker3.php.htm).
5. ir2.ru/test-tracker/limit3000.htm – таблица в 3000 строк (722 KB).
6. ir2.ru/latrus.htm – Латинско-русский словарь (~14000 строк, 1МB), работает с более новой версией скрипта ir2.ru/tabsort3a.js.

Тесты на компьютере Pentium 4 (2.53GHz, Windows XP) показали, что при использовании предложенного алгоритма разбивки на страницы (paginate) работа с таблицей в 3000 строк почти не отличается от работы с таблицей в 200 строк – в «обычном браузере» (Гекко, Хром, Сафари), конечно. В особом браузере (IE) время отрисовки таблицы не зависит от реального отображения элементов и растёт пропорционально количеству строк. Ну, Опера 9.50 тоже, кажется, испытывает трудности с «рисованием».

Во всех примерах настройки можно менять, отмечая галочками элементы checkbox в начале страницы (изменения настроек чаще всего требуют перезагрузки страницы). Например, можно убрать галочку с пункта use_appendChild (активного по умолчанию), и тогда таблица будет отрисовываться с помощью замены innerHTML (что, предположительно, должно было уменьшить время отрисовки). Нет настройки, позволяющей использовать documentFragment, потому что использование documentFragment не дало никакой выгоды ни в одном браузере.

Получившийся скрипт - скорее, инструмент для дальнейших исследований (исключить лишние возможности, оптимизировать код...), но уже сейчас видно, что для эффективной работы с таблицами на стороне веб-клиента нужен комплексный подход - обязательное использование сразу трёх элементов: сортировка, отбор (фильтрация) и разбивка на страницы. При таком подходе вполне можно работать с большими (3000 строк) таблицами прямо в браузере.

Весь набор файлов, необходимых для работы Big Table Sorter'а, находится в архиве ir2.ru/BigTableSorter.zip.

P.S. Спасибо roni за подсказку убрать букву "i" из регэкспа при работе с className.

При отрисовке во время сортировки?

Не надо.

Это кому как надо.

Никто не будет держать shift или control.

Нет. При отрисовке после сортировки! :-) Сортировать реальный ДОМ в 1000 строк нереально, сначала всё грузится в массив, там сортируется, потом вываливается обратно на экран.

(Спасибо за быстрый ответ!)

Ну это понятно, что на экране не сортируется. А зачем создавать заново элементы, если они уже созданы?
Общий алгоритм такой: строки tr помещаем в массив trs, массив сортируем, потом бежим по нему и для каждого элемента просто делаем tbody.appendChild(trs[i]), в результате они выстроятся в нужном порядке.

Ну, может, я неграмотно выразился, но именно это я и назвал "отрисовкой". При appendChild ведь структура ДОМ меняется? И её потом надо перерисовывать?

И, кстати, насчёт создаваемых заново элементов. Как показывает упомянутый выше TinyTable, если помещать строки в массив, копируя (cloneNode), работа с ДОМ идёт гораздо быстрее. Этот фокус позволяет практически уравнять по скорости ИЕ и ФФ (без него ИЕ в несколько раз медленнее, что на таблице в 1000 строк фатально).

Видимо не стоит. Ведь кроме thead, tbody есть и tfoot.

function cmpRowVerse(a, b) {
 a = a[global.sortcell], b = b[global.sortcell];
 try { 
  return (a <= b) ? (a == b) ? 0 : 1 : -1;
 }
 catch(e){return 0;}
}

тут не стоит использовать try catch. он сильно замедляет код и не работает.

А зачем тут try-catch вообще? Операции сравнения ошибку не бросят.

function hasClass(obj, c) {
 //http://ir2.ru/javascript-if.aspx
 if (!c || !obj) return false
 var re = new RegExp('(\\s+|^)' + c + '(\\s+|$)', 'ig')
 if (typeof obj == "string") obj = {className: obj}
 return (re.test(obj.className)) ? re : false
}

а это просто шедевр. извините

Где логика?:-) Если уж вы используете tfoot, про tbody наверняка не забудете. Сейчас скрипт при отсутствии thead сам создаёт этот элемент из первой строчки таблицы. Вопрос в том, сэкономить ли на этом участке кода...