Chart Form Data Hydration#

When a chart opens in the Explore view, its form_data is assembled from up to four sources — permalink, cache, slice DB record, and dashboard context — in a layered pipeline that spans a backend command, a frontend page component, and a Redux action. Understanding this pipeline is essential for debugging unexpected filter state, color scheme issues, or stale chart configurations.

Pipeline Overview#

URL params (permalink key / form_data_key / slice_id / datasource_id)
        │
        ▼
[Backend] GetExploreCommand.run() ← resolves initial_form_data
        │ 1. permalink → GetExplorePermalinkCommand
        │ 2. form_data_key → GetFormDataCommand (Redis/cache)
        │ 3. fallback → slice_id or datasource_id
        │
        ▼
[Backend] get_form_data() ← merges slice DB record
        │ • slice.form_data (DB) is base
        │ • initial_form_data overrides it
        │ • request body/query-string params override further
        │
        ▼
[Backend] convert_legacy_filters, merge_extra_filters, merge_request_params
        │
        ▼
GET /api/v1/explore/ ──────────── response: { form_data, slice, dataset, metadata }
        │
        ▼
[Frontend] ExplorePage (src/pages/Chart/index.tsx)
        │ • reads LocalStorageKeys.DashboardExploreContext[pageId]
        │ • builds dashboardContextFormData via getFormDataWithExtraFilters()
        │ • merges with API result via getFormDataWithDashboardContext()
        │
        ▼
[Frontend] hydrateExplore() ← populates Redux state
           • defaults viz_type, time_range
           • verifies color scheme registry; falls back to default
           • runs getControlsState() + applyMapStateToPropsToControl()
           • dispatches HYDRATE_EXPLORE

Stage 1 — Backend: GetExploreCommand#

GetExploreCommand.run() resolves initial_form_data from one of three inputs, in priority order:

1. Permalink — if permalink_key is set, GetExplorePermalinkCommand fetches the stored state (form data + optional URL params).
2. Cache key — if form_data_key is set, GetFormDataCommand retrieves form data from the cache (Redis by default). If the cache entry is missing, a warning message is set and the fallback below is used 1.
3. Slice / datasource IDs — bare slice_id or datasource_id from URL params become the seed for initial_form_data 2.

This initial_form_data is then passed to get_form_data().

Stage 2 — Backend: get_form_data()#

get_form_data() performs the core server-side merge:

• Starts from initial_form_data as the base dict 3.
• Overlays request body (form_data POST field) and then query-string form_data params — later values win 4.
• If a slice_id is present and use_slice_data=True, loads the Slice record from the DB and applies slice_form_data as the base, then overlays form_data on top — so the saved slice is the baseline and transient params override it 5.
• Calls update_time_range() to normalize legacy time range formats 6.

Back in GetExploreCommand, three additional server-side merges happen after get_form_data() returns 7:

• convert_legacy_filters_into_adhoc — migrates old filter format.
• merge_extra_filters — folds extra_filters into adhoc_filters.
• merge_request_params — injects remaining URL query parameters.

The response payload sent to the frontend includes form_data, slice, dataset, and metadata 8.

Stage 3 — Frontend: Dashboard Context Merge (ExplorePage)#

ExplorePage orchestrates the frontend portion of hydration.

Dashboard context lookup: When Explore is opened from a dashboard tab, SyncDashboardState has already written dashboard state into localStorage under LocalStorageKeys.DashboardExploreContext. ExplorePage reads it back via getDashboardPageContext(pageId) using the dashboardPageId URL param as the key 9.

The retrieved context contains: colorScheme, labelsColor, labelsColorMap, sharedLabelsColors, chartConfiguration, nativeFilters, filterBoxFilters, dataMask, and dashboardId 10.

This context is fed through getFormDataWithExtraFilters() to build a fully populated dashboardContextFormData 11, which is then merged with the API result using getFormDataWithDashboardContext() — but only on the initial page load, not on subsequent re-renders or save actions.

Stage 4 — Frontend: getFormDataWithDashboardContext()#

getFormDataWithDashboardContext() applies the actual merge logic:

• Filter box filters (extra_filters) are converted to adhoc filters, with time-column pseudo-filters (__time_range, __time_col, etc.) mapped to their corresponding form data keys 12.
• Native filters (extra_form_data) are applied via EXTRA_FORM_DATA_OVERRIDE_REGULAR_MAPPINGS and EXTRA_FORM_DATA_OVERRIDE_EXTRA_KEYS, with additional handling for time_grain_sqla and granularity_sqla 13.
• Adhoc filters from all three sources (explore, filter box, native filters) are merged and deduplicated via removeAdhocFilterDuplicates(), then time-range filters are applied via applyTimeRangeFilters() 14.
• Color scheme priority: dashboardColorScheme || ownColorScheme — the dashboard scheme wins; the chart's own scheme is preserved as own_color_scheme 15.
• The final result is a spread merge: { ...exploreFormData, ...dashboardContextFormData, ...filterBoxData, ...nativeFiltersData, ...adhocFilters } 16.

Stage 5 — Frontend: hydrateExplore()#

hydrateExplore() ingests the merged form data and finalizes the Redux state:

• Defaults: viz_type falls back to DEFAULT_VIZ_TYPE → VizType.Table; time_range falls back to DEFAULT_TIME_FILTER → NO_TIME_RANGE 17.
• include_time handling: If include_time is enabled with a granularity_sqla column, it is prepended to groupby and cleared 18.
• Color scheme verification: If the saved color_scheme no longer exists in the scheme registry, it falls back to registryDefaultScheme || 'supersetColors' (categorical) or 'superset_seq_1' (sequential) 19.
• Control state: getControlsState() materializes the control panel state from form data; applyMapStateToPropsToControl() is then run over every control to resolve dependent control values 20.
• Dispatches HYDRATE_EXPLORE with the assembled charts, datasources, and explore state 21.

Key Files#