Kepler.gl построен вокруг предсказуемого и строго структурированного состояния, управляемого через Redux-подобную модель. Вся логика визуализации, фильтрации, взаимодействий и конфигурации карты сведена к нескольким крупным доменам состояния, которые развиваются независимо, но синхронизируются через единый поток действий.
Состояние Kepler.gl делится на несколько ключевых срезов, каждый из которых отвечает за отдельный слой системы визуализации.
visState является наиболее насыщенной частью состояния. Он управляет данными и тем, как они отображаются.
Внутри visState находятся:
Каждый dataset хранится в нормализованной форме. Это важно: Kepler.gl не работает с «сырыми таблицами» напрямую, а преобразует их в структуру, удобную для быстрого рендера через deck.gl.
Перед добавлением в состояние данные проходят трансформацию:
Это позволяет избегать повторных вычислений при каждом рендере.
mapState отвечает за то, как именно пользователь видит карту.
В него входят:
mapState напрямую связан с viewState deck.gl. Любое изменение этого среза приводит к перерасчёту матрицы камеры и перерисовке слоёв.
Особенность архитектуры заключается в том, что mapState не содержит логики — только числовое описание состояния камеры. Все вычисления вынесены в слой рендера.
uiState управляет состоянием интерфейсных компонентов, не связанных напрямую с геометрией карты.
Сюда входят:
uiState изолирован от visState, что предотвращает смешивание визуальной логики и интерфейсной структуры.
Отдельный подслой отвечает за временные взаимодействия:
Этот слой живёт короткими циклами: он часто перезаписывается и не предназначен для долгосрочного хранения. Его задача — отражать текущее мгновение взаимодействия пользователя с картой.
Kepler.gl использует архитектуру, основанную на Redux reducer-цепочке, где каждый срез состояния управляется своим редьюсером.
Центральная функция:
Каждый экземпляр Kepler.gl (например, несколько карт на странице) может иметь собственное пространство состояния, что достигается через namespacing reducer’ов.
Состояние строго иммутабельно. Любое изменение приводит к созданию нового объекта:
Для оптимизации используются:
Все изменения проходят через action-based систему.
ADD_DATA_TO_MAP — добавление данныхADD_LAYER — создание слояUPDATE_LAYER — изменение параметров слояADD_FILTER / UPDATE_FILTER — фильтрация
данныхINTERACTION_CHANGE — изменения взаимодействийMAP_STATE_CHANGE — движение камерыКаждое действие проходит через middleware слой, где может быть:
Kepler.gl активно использует концепцию производного состояния.
Примеры:
Важно, что derived state не хранится напрямую, а пересчитывается при необходимости, но с кэшированием результатов.
Kepler.gl является обёрткой над deck.gl, поэтому значительная часть состояния трансформируется в props для deck.gl layers.
Процесс выглядит так:
Таким образом, Redux состояние выступает промежуточным слоем между UI и WebGL рендерингом.
Одной из ключевых особенностей архитектуры является возможность экспорта и импорта состояния.
Состояние преобразуется в JSON, включающий:
При восстановлении выполняется обратная процедура:
Это позволяет сохранять полноценные проекты карт и переносить их между средами.
Kepler.gl поддерживает несколько независимых экземпляров на одной странице.
Это достигается через:
Каждый инстанс имеет собственные:
При этом глобальный store может содержать сразу несколько карт, не конфликтующих между собой.
Middleware используется для:
Расширяемость достигается через возможность внедрения собственных middleware между dispatch и reducer.
Архитектура состояния учитывает работу с большими объёмами данных:
Это позволяет системе сохранять интерактивность даже при миллионах точек.
Селекторы являются критическим элементом архитектуры:
Они изолируют React-компоненты от внутренней структуры Redux, обеспечивая стабильный API для UI слоя.
Особенность Kepler.gl заключается в тесной синхронизации между:
Например, изменение фильтра в visState может привести к:
При этом mapState остаётся неизменным, что сохраняет стабильность пользовательского восприятия.
Для борьбы со сложностью применяется несколько принципов:
Эта дисциплина позволяет удерживать масштабируемость даже при росте количества слоёв, фильтров и датасетов.