Таблицы

Введение

Всем добрый день. Меня зовут Александр. Сейчас я работаю в Мегафон front-end разработчиком. Проблемы поиска данных всегда отличались особенной сложностью и зачастую нестандартностью в подходах. Сегодня я бы хотел остановиться на одной интересной задаче, которую мне пришлось решать совсем недавно во время разработки платформы Интернета вещей. Впрочем, такая задача, может встретиться и на любом другом проекте, где есть динамическая подгрузка данных по REST API. Будь то подгрузка во время пагинации, или во время скроллинга, или как то иначе

Проблематика

Казалось бы: в чем может быть трудность. Особенно когда речь касается только фронта? Ведь все алгоритмы поиска реализуются в основном на бэке. На самом деле и да, и нет. Давайте представим простую таблицу, у которой есть пагинация из нескольких страниц и фильтр на каждом столбце. См. ниже.

В данной табличке открыт фильтр по столбцу Номер БС. Простыми словами: вводя любые символы в поле ввода фильтра, вы получаете подходящие опции в дропдауне. Кликнув на любую из них, вы отфильтруете данные в таблице по этому элементу.

Каким образом можно вывести подобный дропдаун с нужными опциям?

Варианты решения

1. Составить массив из всех элементов столбца таблицы и с помощью методов filter и includes (или им подобных) показать нужные опции в дропдауне. Проблема в том, что компонент таблицы не знает о элементах, которые находятся на других страницах. Они подгружаются только при переходе на эти страницы. А значит поиск будет осуществляться не по всем элементам.

2. Сформировать массив как в 1-м варианте, но запрашивая его с бэка. Хороший вариант, но производительность такого подхода близится к 0. Что если записей 1 млн? В таблице именно для этого и используется пагинация.

3. Отправлять строку фильтра на бэк, и уже с бэка получать нужные опции для дропдауна. Бэк знает обо всех записях и на нем можно использовать всевозможные алгоритмы поиска в базах данных, которые будут работать достаточно быстро.

   Отлично. Именно этот вариант мы и рассмотрим. На рисунке выше изображен именно он: мы ищем записи, которых нет на текущей странице, однако в дропдауне видим подходящие варианты со всех страниц.

Алгоритм

1. Для каждого столбца должен существовать запрос на бэк и поле, которое мы будем брать из ответа, чтобы заполнить опции. Нужен config.

2. После ввода данных их нужно отправлять на бэк. Можно по кнопке, но лучше использовать периодическую отправку в функции debounce.

3. Во время процесса отправки/получения данных показывать loader

4. Получения ответа от бэка и заполнение опций для дропдауна из заданного поля ответа

Решение

Я предполагаю, что читатели знакомы с JS и React и в данной статье нет смысла рассказывать о том, как отправлять запросы, фильтровать массивы и другие основы JS. Я буду останавливаться лишь на важных составных частях алгоритма.

Итак, начнем по порядку. Как мы выяснили, для начала нужен конфиг для таблицы (для каждого столбца) и ее фильтров. Разделим его на 2 файла.

Пример конфига столбца таблицы:

{  id: 'address',  title: 'Адрес объекта',  filter: filters.address,  checked: true,  minWidth: 160}

Пример конфига фильтра:

address: {  type: 'includes',  name: 'addrFilter',  options: {    default: {      values: 'objectsList',      fetchFunc: 'fetchObjectsList',      calcFunc: 'address'    }  }}

Как можно заметить конфиги связаны по типу один-ко многим. То есть один и тот же фильтр может соответствовать нескольким столбцам таблицы.

Поле options содержит как раз поля для конфигурации опций фильтра. Например:

• fetchFunc - имя thunk функции, которая загружает данные для этого фильтра

• values - поле из ответа сервера, в котором содержатся опции

• calcFunc - имя функции для трансформирования опций

Остановимся подробнее на calcFunс. При таком алгоритме, что был описан в опции попадают данные из определенного поля ответа. Но что если поле составное, например в каждую опцию фильтра должно попасть сразу несколько полей. Пример с адресом: опция фильтра = город + улица + дом

В этом нам и поможет функция предварительного обсчета опции. Вот пример реализации:

//object includes calc functionsconst calculatedData = useMemo(() => (  {    default: (values) =>    {      //default calculate    },    address: (values) =>    {      //calculate with generateAddress function, for example    },    ...}), [...]);//using this object (calcFunc from config):const data = calculatedData[calcFunc || 'default'](values)

Далее. Как уже говорилось лучше всего отправлять запросы через определенный интервал задержки. То есть пользователь вводит данные в поле, приостановился на полсекунды - произошла отправка. Реализуется это примерно так:

// debounce functionconst debounce = (fn, ms = 0) => {  let timeoutId;  return function(...args) {    clearTimeout(timeoutId);    timeoutId = setTimeout(() => fn.apply(this, args), ms);  };};//debounceFetch functionconst debounceFetch = debounce(async (func, args) =>   typeof func === 'function' && (await func(args)), 500);//sending requestuseEffect(() => {  debounceFetch(actions[fetchFunc], {     filter: { [filterName]: filterValue || null }   });}, [filter]);

Продолжаем. В текущей задаче может понадобиться определить грузится ли в данный момент какой-либо фильтр, например, чтобы показать лоадер. У нас в команде приняты некоторые стандарты для именования переменных, например, все переменные, показывающие процесс загрузки начинаются с isLoading. Например, isLoadingObjects. Поэтому идеальным решением будет создать selector для kea, который = true если хотя бы в одном стейте, содержащем в названии isLoading, содержится значение true.

Если вы используете не kea, а обычный redux или какую-то другую библиотеку - уверен, вы адаптируете этот код под свои нужды. Если нет - пишите мне. А лучше используйте kea =)

Далее вы просто показываете лоадер пока anyLoading===true, все как обычно.

На этом мы почти закончили. Далее нужно просто обработать ответ сервера, взять нужное поле из него, пропустить его через calcFunc если она указана в конфиге и вывести найденные опции для фильтра.

Всю логику лучше всего будет объединить в один хук и назвать его, скажем, useFiltersOptions.

Выводы

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

А также используются уже имеющиеся запросы к бэку, а в конфиге указываются лишь их названия и поля из ответа для формирования результатов поиска, что позволяет избежать дублирования кода и лишней работы на стороне бэка.

Для кого эта статья

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

Проблема

Проблема у дизайнера начинается в тот момент, когда таблица из десктопной версии интерфейса адаптируется под мобильные устройства. Как мы знаем таблицы могут иметь много столбцов, что влечёт за собой вылеты талицы за ширину экрана на мобильном устройстве.

Данная проблема встречается повсеместно, и усугубить ее может пожалуй лишь контент ячейки, который не переносится построчно, увеличивая тем самым ширину колонки.

Подопытный набор данных

Для того чтобы понимать лучше суть проблемы, мы придумаем себе таблицу, и будем ее адаптировать.

Колонки:

1. Номер

2. Фото

3. ФИО

4. Телефон

5. Email

6. Дата

7. Текст описание

8. Статус

9. Действия

Результатом станет довольно обширная таблица, которая имеет все нужные нам виды колонок. Признаться даже список сверху вызывает у меня вопросы справа тратится слишком много места.

1. С фиксированной шириной и переносом строк

2. С шириной по контенту

Анонс следующей статьи О списках в интерфейсах и как их применять по феншую.

Десктоп

В окне браузера наша таблица будет довольно комфортно себя чувствовать. Мы можем контролировать отображение контента так, как нам нужно. Даже если таблица перестанет помещаться по ширине то мы всегда можем либо скрыть пару колонок с самым низким приоритетом, либо в крайнем случае сделать скроллинг по горизонтали.

Варианты адаптации

Проблема наша талица по ширине не влезает в телефон.

Ошибочные решения

1. Уменьшать шрифт

2. Убирать колонки

3. Делать растровую картинку с таблицей и вставлять ее в макет

Возможные верные решения по убыванию

1. Каждую строку таблицы делать блоком

2. Горизонтальный скроллинг

Первый вариант адаптации - сделать каждую строку таблицу отдельным блоком, и вывести ее на экране телефона.

Проблема с данным методом: Удлиняется вертикальный скроллинг, данные повторяются. (частично решается добавлением фильтров для поиска)

Возьмём за пример таблицу, которая отображена сверху. В таком виде она не поместится по ширине в мобильный экран. Для решения этой проблемы мы будем каждую строку таблицы преобразовывать в блок.

Таким образом мы добьемся максимальной читаемости таблицы, без потери данных. Мы видим в строке все столбцы, при необходимости можем сделать функцию поиска, а так же добавить сортировки для блоков. Проблемой при данном подходе является длинный скролинг.

Второй вариант - горизонтальный скролинг таблицы.

Для реализации данного подхода - нам нужно взять таблицу из декстопной версии сайта, и поместить ее в мобильный экран, а весь тот контент, который не помещается по ширине вынести за границы экрана, добавив при этом горизонтальную прокрутку к скрытым столбцам.

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

Вывод

Теперь адаптация таблиц не должна нам казаться невыполнимой задачей, мы научились делать так, чтобы таблицы были удобоваримыми не только на десктопной версии сайтов, но и в мобильной (что применимо и к мобильным приложениям).

Если вы заметили ошибки, или вам есть что дополнить - дайте мне знать, я обязательно это сделаю.Спасибо за внимание!

Короткое резюме 10 постулатов по улучшению таблиц, опубликованных в Journal of Benefit Cost Analysis экономистом Jon Schwabish.

Перед тем как переходить к 10 постулатам для улучшения таблиц, давайте осознаем, что как и в графиках, и в диаграммах, таблицы состоят из большого количества деталей. И грамотно проработав все эти детали, мы можем контролировать внешний вид таблицы.

Итак, перейдем к правилам.

1. Отделяйте заголовки от тела таблицы

Делайте заголовки своей таблицы понятными. Старайтесь использовать жирный шрифт или линии, чтобы отделить заголовки от тела таблицы - чисел и текста.

2. Используйте ненавязчивые разделители вместо толстой сетки

Облегчите или вообще удалите большинство тяжеловесных краев и разделителей в Вашей таблице. Редко бывает, что границы необходимы для всех ячеек.

3. Выравнивайте числа и заголовки по правому краю

Выравнивайте числа по правому краю по уровню десятичной точки. Возможно, понадобится добавить дополнительную нули, чтобы поддержать выравнивание, но оно того стоит - числа становятся более читаемыми.

4. Выравнивайте текст и заголовки по левому краю

Как только мы выровняли числа по правому краю, нужно выровнять текст по левому краю. Обратите внимание, насколько названия стран в самом правом столбце лучше воспринимаются по сравнению с первыми двумя столбцами.

5. Выбирайте адекватный уровень точности

Точность до пятого знака после запятой едва ли бывает нужна. Ищите баланс между необходимой точностью и чистой, аккуратной таблицей.

6. Направляйте читателя с помощью расстояний между строками и столбцами

То, как Вы используете пробелы внутри и вне таблицы, влияет на порядок восприятия Вашими читателями. Используйте расстояния стратегически правильно, чтобы направить читателя в нужном Вам русле.

7. Избегайте повтора единиц измерения

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

Примечание от редактора: можно еще поместить единицы измерения в шапку таблицы, вместе с заголовком. Именно так всех учили оформлять лабораторные по физике и финансовые таблицы. Что ж, в этом есть определенный смысл.

8. Выделяйте выбросы

Некоторые читатели будут подробно изучать все значения в таблице, потому что им нужна специфическая информация, но большинство людей интересуют только самые значимые значения.

9. Группируйте похожие данные и отделяйте их пробелами

Уменьшайте количество повторов за счет объединения похожих данных или подписей. Аналогично повторам единиц измерения, мы можем сделать таблицу чище за счет группировки данных по смыслу.

10. Добавляйте визуализацию при необходимости

Мы можем кардинально изменить внешний вид нашей таблицы, добавив в нее маленькие визуализации. Они делают таблицу более наглядной и позволяют проще выделять тренды и паттерны, на которые нам бы хотелось обратить внимание читателя.

Эпилог

До этого мы приводили лишь отдельные примеры для каждого постулата, а теперь применим все накопленные знания на примере. Ниже - исходная таблица и ее переработанный вариант.

Разница в наглядности очевидна. Проведите ревизию своих ежедневных и финансовых отчетов - а у Вас все правила соблюдаются? ;)