Kepler.gl построен поверх Redux и рассматривает состояние приложения как единый источник истины. Вся карта, наборы данных, стили слоёв, фильтры и интерфейсные параметры хранятся в централизованном store, что делает отладку предсказуемой, но требует понимания структуры состояния.
Ключевая идея заключается в разделении состояния на несколько крупных доменов:
Каждый из этих сегментов управляется собственными редьюсерами, но объединяется в единый store через root reducer.
Состояние Kepler.gl обычно выглядит как вложенный объект следующего уровня:
keplerGl
map
При интеграции в приложение часто используется ключ
keplerGl, внутри которого может находиться несколько
независимых экземпляров карты. Это важно при отладке мультикартовых
приложений.
Каждый экземпляр идентифицируется уникальным ключом:
keplerGl.map1keplerGl.dashboardMapkeplerGl.analysisViewОтладка состояния без учета ключа экземпляра приводит к ошибочным выводам, поскольку изменения могут происходить только в одном из них.
Redux DevTools является центральным инструментом отладки Kepler.gl. Он позволяет отслеживать:
В Kepler.gl действия имеют строгую структуру и часто сопровождаются payload, содержащим большие вложенные объекты (геоданные, стили слоёв, параметры фильтров).
Особенность заключается в том, что некоторые actions могут быть агрегированными:
ADD_DATA_TO_MAPADD_LAYERLAYER_CONFIG_CHANGEUPDATE_MAP_STATEКаждое действие изменяет только часть дерева состояния, поэтому важно анализировать не только action, но и итоговое состояние после редьюсинга.
visState является наиболее сложным сегментом состояния. Он включает:
Типичная проблема при отладке связана с несоответствием состояния слоёв и данных.
dataId в конфигурации слояОтладка таких случаев начинается с проверки связки:
Любое несоответствие приводит к «пустым» слоям без визуального представления.
mapState управляет геометрией представления:
Основная сложность при отладке заключается в асинхронных обновлениях состояния. Например, изменение слоя может инициировать автоматическую подстройку карты.
Типичные проблемы:
При анализе важно отслеживать последовательность actions:
UPDATE_MAP_STATEADD_DATA_TO_MAPUPDATE_MAP_STATEИногда порядок приводит к неожиданным визуальным эффектам.
uiState часто недооценивается при отладке, хотя именно он управляет поведением интерфейса:
Ошибки здесь проявляются как «неработающий интерфейс», хотя данные и слои корректны.
Типичный пример:
Причина часто заключается в uiState, где флаг активности панели не обновился после dispatch.
mapStyle управляет базовой картой и визуальной темой. Включает:
При отладке важно проверять:
Ошибки в mapStyle часто визуально выглядят как «пустая карта», хотя данные присутствуют.
Kepler.gl активно использует Redux actions для управления всеми изменениями состояния. Каждое действие проходит через pipeline:
Middleware может модифицировать payload, что усложняет отладку.
Особенно важно учитывать:
При анализе DevTools необходимо проверять не только итоговое состояние, но и промежуточные actions, так как именно в них часто теряется информация.
Redux DevTools и persistence слои требуют сериализуемого состояния. Kepler.gl оперирует большими структурами данных, что иногда приводит к проблемам:
Такие структуры могут:
Решение заключается в анализе «чистого» JSON представления состояния и выявлении несериализуемых фрагментов.
Kepler.gl использует селекторы для извлечения данных из store. При сложных состояниях важно учитывать:
Ошибки селекторов проявляются как:
При анализе состояния важно отделять raw state от computed state, так как именно computed слой часто является источником рассинхронизации.
При интеграции Kepler.gl в существующее Redux-приложение часто возникает конфликт структуры store.
Типовые проблемы:
Особенно критично, когда внешнее приложение также использует actions с похожими именами, что может приводить к непреднамеренным обновлениям состояния.
Kepler.gl поддерживает мультикарточные конфигурации. В этом случае состояние выглядит так:
Ошибки часто возникают при:
При анализе Redux DevTools важно фильтровать actions по instanceId, иначе логика обновлений становится неочевидной.
Размер Redux состояния Kepler.gl может быть значительным, особенно при больших геоданных. Это влияет на:
Проблемы производительности часто выглядят как «зависания интерфейса», хотя причиной является частое обновление visState или неэффективные редьюсеры.
Отладка включает анализ:
При анализе Redux состояния Kepler.gl применяются повторяющиеся паттерны:
Особое внимание уделяется моментам, когда состояние корректно обновляется, но UI не отражает изменения — это почти всегда указывает на проблему в uiState или selectors.
Загрузка данных в Kepler.gl проходит через несколько этапов:
При отладке важно учитывать промежуточные состояния, когда dataset уже существует, но слой ещё не создан. В этот момент UI может находиться в частично инициализированном состоянии, что часто ошибочно интерпретируется как сбой рендера.