Обновление таблицы без мерцания: как показать загрузку и сохранить контекст строк

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

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

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

Пользователь видит одинаковые строки, но причина состояния может быть разной. Минимально полезная модель включает:

Эти состояния нельзя сводить к одному «Загрузка…» или общей пустой заглушке. Иначе интерфейс скрывает, что уже знает, а чего ещё не знает.

При первом открытии страницы пользователь пока не видел данные. Если реальная оценка длительности запроса недоступна, не показывайте обратный отсчёт или выдуманный процент выполнения. Достаточно сообщить, что список загружается, и сохранить контур таблицы: колонка выбора, заголовки, примерная высота строк. Это удерживает геометрию страницы и помогает понять, где искать результат.

Скелетон уместен, если данные действительно скоро появятся и структура таблицы уже известна. Не делайте десятки мигающих прямоугольников: они создают движение без информации. Спокойный индикатор и текст «Загружаем записи» обычно понятнее. Если загрузка может затянуться из-за большого файла или сложного расчёта, покажите отдельный ход операции с доступным описанием, например «Формируем отчёт. Можно продолжить работу в другом разделе» — но только если это соответствует поведению системы.

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

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

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

Не делайте старые данные визуально неотличимыми от только что подтверждённых, если точность свежести важна. В таком случае рядом с обновлением укажите, что отображается последний успешно полученный результат, и оставьте метку времени из надёжного источника. Это связано с темой актуальности данных, но не заменяет её: метка отвечает на вопрос «когда?», индикатор — «что происходит сейчас?».

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

Выберите один способ и используйте его последовательно. Не меняйте фильтр, а затем оставляйте старые данные без сигнала: это создаёт ложное соответствие между условием и результатом. И не сбрасывайте страницу на первую при каждом обновлении, если параметры поиска не менялись. Если изменение фильтра сделало текущую страницу недоступной, верните пользователя к последней существующей странице либо к первой и коротко сообщите об этом.

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

После успешного ответа без записей дайте точное объяснение с учётом причины. «В этой таблице пока нет данных» подходит для пустого набора. «По выбранным фильтрам ничего не найдено» — для нулевой выборки. Во втором случае полезно предложить снять один фильтр или очистить условия целиком. Не предлагайте «создать запись», если у пользователя нет права на создание или таблица лишь показывает результаты поиска.

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

Если фоновое обновление не удалось, последний успешно полученный набор может быть полезнее пустого экрана. Сохраните его, обозначьте, что обновление завершилось ошибкой, и предложите повторить попытку. Например: «Не удалось обновить список. Показаны данные, загруженные ранее» — только если это действительно так. Время последнего успешного ответа помогает человеку оценить, можно ли пока продолжать работу.

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

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

Не показывайте эти фразы одновременно в нескольких местах. Если индикатор рядом с таблицей уже сообщает «Обновляем список», дополнительный глобальный баннер с тем же сообщением только добавит шум.

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

Оставить старые строки без объяснения. После смены фильтра они могут быть восприняты как соответствующие новому условию. Покажите переходное состояние или дождитесь ответа перед применением нового условия.

Использовать один текст для пустоты и ошибки. «Ничего не найдено» утверждает, что запрос завершился успешно. При сбое такого знания нет.

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

Блокировать все действия. Ограничение должно соответствовать конкретному риску. Чтение и копирование старого результата могут оставаться допустимыми, тогда как массовое изменение — нет.

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

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

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

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

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

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

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

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

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