Устранение задержек как архитектура, а не набор приёмов: оптимистичные мутации, уровни кэша, защита от лавины запросов, отложенный хвост — каждое измерено против наивной версии.
Та половина Velocity, которую пользователь чувствует. Ничто из этого не ускоряет сервер.
Обе колонки говорят с одним и тем же симулированным сервером. Одна его ждёт, другая применяет намерение сразу и сверяется позже.
Блокирует на 500 мс при каждом клике.
Применяет сразу; то же подтверждение через 500 мс приходит следом.
Только для обратимых и предсказуемых действий. Платежи, удаления и изменения прав никогда не бывают оптимистичными: откат, возвращающий право, которого у пользователя не было, хуже ожидания.
Шесть уровней спекуляции поверх собственных триггеров SvelteKit. Атрибуты ниже прочитаны из модуля, а не перепечатаны.
| Намерение | Код | Данные | Для чего |
|---|---|---|---|
none | off | off | Дорогие, редко используемые или изменяющие ссылки. |
code | viewport | off | Дорогой маршрут: прогреть чанк, не тратя ничего на сервере. |
data | hover | hover | Обычный случай, совпадающий с общим для приложения hover. |
code-data | viewport | tap | Ссылки с высокой вероятностью перехода: чанк заранее, данные по нажатию. |
idle | off | off | Управляется preloadOnIdle после того, как страница стала интерактивной, а не атрибутом. |
Данные никогда не загружаются от одной лишь видимости. На странице с сорока ссылками триггер по вьюпорту выполнил бы сорок загрузок маршрутов ради того, кто просто пролистал мимо.
Длинный список должен стоить как область просмотра, а не как объём данных. Переключите число строк и посмотрите, что остаётся в DOM.
Только одинаковая высота строк, и это намеренно: переменная высота требует измерений и таблицы смещений, а каждое из этого — источник скачков прокрутки. Стрелки, Page Up/Down, Home и End двигают перемещаемое выделение — строк, по которым можно было бы пройти табом, по большей части не существует.
Думаете, этот паттерн можно сделать лучше? Расскажите как.
Оставить отзыв