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

[stopkran]

Примерно год назад начал работу над скриптом 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.

[Kolyaj]

Использовать при отрисовке таблицы innerHTML или appendChild?

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

Делать ли таблицу полосатой («зебра»)?

Не надо.

Разбивать ли на страницы (paginate)?

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

Давать ли возможность пользователям самим определять тип сортировки (удерживая при щелчке Shift или Control)?

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

[stopkran]

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

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

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

[Kolyaj]

сначала всё грузится в массив, там сортируется, потом вываливается обратно на экран.

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

[stopkran]

и для каждого элемента просто делаем tbody.appendChild(trs[i])

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

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

[with-love-from-siberia]

Заставлять ли разработчика явно обозначать элементы thead и tbody?

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

[vflash]

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. он сильно замедляет код и не работает.

[Kolyaj]

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

[vflash]

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
}

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

[stopkran]

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

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