Обработка пользовательских действий в Kepler.gl строится вокруг реактивной архитектуры, где каждое взаимодействие пользователя транслируется в состояние приложения через единый поток данных. Это позволяет синхронизировать карту, слои, фильтры и визуализации без прямого императивного управления DOM или WebGL-сценой.
Система взаимодействий в Kepler.gl опирается на связку React + Redux + deck.gl. Пользовательские действия не обрабатываются напрямую внутри визуальных компонентов — они проходят через слой действий (actions), которые изменяют глобальное состояние.
Основные принципы:
Каждое событие, будь то клик по объекту или изменение фильтра, превращается в action, который обновляет состояние и вызывает повторный рендер слоёв.
Навигационные действия включают:
Эти изменения фиксируются в состоянии mapState.
Типовой поток:
mapStateКлючевая особенность — отсутствие прямого управления камерой, всё проходит через обновление состояния.
Обработка клика является одной из самых важных частей интерактивности.
События клика проходят через pick-процесс deck.gl:
Далее вызывается action выбора объекта:
selectedFeatureОсобое внимание уделяется производительности: pick-операции оптимизированы через spatial indexing внутри deck.gl.
Hover реализуется как непрерывный поток событий при движении мыши:
hoverInfo в состоянииHover используется для:
Для снижения нагрузки применяется throttling, особенно при плотных датасетах.
Все пользовательские действия преобразуются в Redux actions.
Основные категории:
updateMapStateinteractionStateChangelayerClicksetFilteraddDataToMapКаждый action проходит через reducer, который формирует новое состояние приложения.
Пример логики:
Такой подход исключает необходимость ручного управления состоянием карты.
Пользовательские действия напрямую влияют на состояние слоёв:
События UI:
Каждое изменение обновляет visState.layers.
Слои могут поддерживать:
Например, при клике по кластеру выполняется:
Перетаскивание используется в нескольких сценариях:
Система реализована через:
Особое внимание уделяется согласованности состояния при одновременных drag-операциях и обновлениях карты.
Фильтры являются одним из ключевых механизмов интерактивности.
Типы взаимодействий:
Каждое изменение:
setFilterФильтрация реализована так, чтобы минимизировать пересчёт данных — используется мемоизация и кэширование промежуточных результатов.
Map events включают:
Kepler.gl хранит interactionConfig, который
определяет:
Это позволяет гибко управлять UX без изменения логики компонентов.
Архитектура позволяет переопределять поведение событий:
Распространённые сценарии:
Middleware слой позволяет перехватывать actions до reducer, что удобно для логирования и аналитики.
При интенсивных взаимодействиях ключевыми становятся оптимизации:
deck.gl использует структуры данных для ускорения pick-операций:
Несколько actions могут объединяться в один batch для снижения количества рендеров.
Некоторые пользовательские действия запускают асинхронные процессы:
Эти процессы управляются через middleware (например, redux-thunk), а результат возвращается в store как новый dataset.
Kepler.gl допускает расширение UI через React-компоненты, которые могут:
Это позволяет создавать:
При одновременных взаимодействиях возможны конфликты:
Для решения применяются:
При использовании нескольких экземпляров Kepler.gl:
Это особенно важно для сравнительных визуализаций.
Система учитывает возможные сбои:
Обработка ошибок встроена в reducer и middleware, предотвращая разрушение состояния приложения даже при некорректных действиях пользователя.