You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "georgeteena (via GitHub)" <gi...@apache.org> on 2026/06/18 06:51:20 UTC
[D] Scalable way to customize Superset for UX improvisation [superset]
GitHub user georgeteena created a discussion: Scalable way to customize Superset for UX improvisation
Hi,
Since we started using Superset (currently v6.0.0), we received some feedback dashboard level filters (e.g. auto-apply filter selection without the `apply` button).
I read about developers customising the community version. What's a scalable and least painful way to do this, while keeping up to date with Superset's latest stable versions? Note - we are not going for a look and feel overhaul. Our goal is mostly functional and utilitarian.
Thanks!
@dosu
GitHub link: https://github.com/apache/superset/discussions/41185
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Scalable way to customize Superset for UX improvisation [superset]
Posted by "georgeteena (via GitHub)" <gi...@apache.org>.
GitHub user georgeteena added a comment to the discussion: Scalable way to customize Superset for UX improvisation
@dosu,
I am using feature flags and `superset_config.py` for customisations. But we need to do one or two UX improvements.
> Frontend modification — Modify the FilterBar component's handleApply logic to auto-dispatch https://github.com/apache/superset/issues/37069, but this means maintaining a fork of frontend code, which is the least scalable path
> anything not in a plugin or config file will create merge conflicts on every upgrade
This is what I noticed as well. Keeping the fork updated is difficult with all the merge conflicts, and build steps fail. There are 1000s of forks today, so I wonder how these forks are maintained and or updated.
GitHub link: https://github.com/apache/superset/discussions/41185#discussioncomment-17348088
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Scalable way to customize Superset for UX improvisation [superset]
Posted by "FrancescoCastaldi (via GitHub)" <gi...@apache.org>.
GitHub user FrancescoCastaldi added a comment to the discussion: Scalable way to customize Superset for UX improvisation
The most scalable way to customize Superset without falling into maintenance debt or painful merge conflicts on every upstream release is to use **extension points and configuration layers** rather than forking the core frontend codebase.
Here is the recommended hierarchy of customizations, ordered from least maintenance to most:
### 1. Configuration & Feature Flags (`superset_config.py`)
Many UX behaviors (including dashboard filters) are configurable out of the box:
- **Auto-apply native filters without the Apply button:** In native filter configuration, check "Auto-apply filter changes on selection" or configure `DASHBOARD_NATIVE_FILTERS: True` with default auto-apply behavior.
- **Theme Variables:** Superset 6.x supports Ant Design theme token overrides through `THEME_OVERRIDES` in `superset_config.py`, allowing you to adjust brand colors, corner radius, padding, and font sizes across all pages without rebuilding assets.
### 2. Dashboard Custom CSS (Zero Maintenance on Upgrade)
For utilitarian UX adjustments (such as hiding specific buttons, adjusting card margins, or highlighting active tabs):
- Use **Edit Dashboard -> Edit CSS**.
- CSS rules live in the Superset metadata database rather than container source code. They persist seamlessly across version upgrades.
### 3. Dynamic Plugins for Custom Visualizations (SIP-38)
If you need custom chart controls or tables:
- Never edit plugins inside `superset-frontend/plugins/`.
- Build your custom plugin as a separate npm package using `@superset-ui/generator-superset`.
- Set `DYNAMIC_PLUGINS = True` in `superset_config.py` and register the plugin at runtime via URL or an administrative script.
### 4. Docker Multi-Stage Asset Overlay (If you must patch files)
If a functional requirement strictly necessitates modifying a core frontend file (e.g., `FilterBar.tsx`):
- Maintain your changes as isolated `.patch` files or discrete source files in your deployment git repository.
- Use a multi-stage Dockerfile that builds from the official release tag:
```dockerfile
FROM apache/superset:6.1.0 AS custom
COPY ./patches/FilterBar.tsx /app/superset-frontend/src/dashboard/components/nativeFilters/FilterBar/FilterBar.tsx
# Rebuild only the frontend bundle layer
```
This keeps your base image pinned to official security releases while keeping your customizations transparent and easily rebased.
GitHub link: https://github.com/apache/superset/discussions/41185#discussioncomment-19164794
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Scalable way to customize Superset for UX improvisation [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Scalable way to customize Superset for UX improvisation
<!-- Answer -->
Great question! Here's a practical breakdown of how to customize Superset scalably while staying upgradeable:
**Prioritize these customization methods (in order of maintainability):**
1. **Configuration overrides via `superset_config.py`** — Create your own config file and set it via `SUPERSET_CONFIG_PATH`. Only override the settings you need; Superset imports your file at the end of its core config [[1]](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/docs/docs/configuration/configuring-superset.mdx#L18-L22). This survives upgrades cleanly.
2. **Feature flags** — Toggle functionality on/off without code changes. Set them in your `superset_config.py` under `FEATURE_FLAGS` dict [[2]](https://github.com/apache/superset/wiki/Community-Resource-Library).
3. **Visualization plugins** — For custom chart types, build standalone plugins using the `ChartPlugin` class. This has explicit backward-compatibility guarantees—breaking changes only happen in major releases [[3]](https://github.com/apache/superset/wiki/Semantic-Versioning).
4. **CSS customization** — For styling tweaks, use dashboard-level CSS to target specific elements without touching core code [[2]](https://github.com/apache/superset/wiki/Community-Resource-Library).
**Regarding auto-apply filters:** Unfortunately, there's currently no built-in feature flag or configuration to remove the "Apply" button and auto-apply filter selections. This is a [known community request](https://github.com/apache/superset/issues/36876) — maintainers have acknowledged it "differs from most BI tools and UX expectations," but it hasn't been implemented yet. Your options are:
- **URL parameters** — Pre-apply filters when loading dashboards via the `native_filters` URL parameter (rison-encoded), useful for linked navigation [[4]](https://github.com/apache/superset/discussions/40514#discussioncomment-17101532)
- **Frontend modification** — Modify the FilterBar component's `handleApply` logic to auto-dispatch [[5]](https://github.com/apache/superset/issues/37069), but this means maintaining a fork of frontend code, which is the *least* scalable path
**For staying current across upgrades:**
- Superset follows semantic versioning with a structured deprecation process — deprecated features get a feature flag first, then removal only in major releases [[3]](https://github.com/apache/superset/wiki/Semantic-Versioning)
- Keep customizations isolated to `superset_config.py` and standalone plugins
- Test upgrades in staging, paying special attention to major version bumps
- Avoid modifying core frontend/backend code directly — anything not in a plugin or config file will create merge conflicts on every upgrade
For your specific use case (functional/utilitarian changes, not visual overhaul), I'd recommend staying on the config + feature flags path for everything possible, and tracking upstream issues like the auto-apply filter request to avoid maintaining custom patches longer than necessary.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apache%2Fsuperset).*
---
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=apache%2Fsuperset).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=apache%2Fsuperset&message_id=e721cc2a-51c6-4f57-afb8-5b327c9bd25f) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=apache%2Fsuperset) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/41185#discussioncomment-17347959
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Scalable way to customize Superset for UX improvisation [superset]
Posted by "georgeteena (via GitHub)" <gi...@apache.org>.
GitHub user georgeteena edited a discussion: Scalable way to customize Superset for UX improvisation
Hi,
Since we started using Superset (currently v6.0.0), we received some feedback on dashboard level filters (e.g. auto-apply filter selection without the `apply` button).
I read about developers customising the community version. What's a scalable and least painful way to do this, while keeping up to date with Superset's latest stable versions? Note - we are not going for a look and feel overhaul. Our goal is mostly functional and utilitarian.
Thanks!
@dosu
GitHub link: https://github.com/apache/superset/discussions/41185
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Scalable way to customize Superset for UX improvisation [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Scalable way to customize Superset for UX improvisation
<!-- Answer -->
You're hitting the core tension — Superset's frontend extensibility for *behavioral* changes (not just charts or styling) is genuinely limited right now. Here's the honest picture:
**Why most forks struggle:** The community consensus is that most of those 1000s of forks are either (a) not kept up to date, (b) pinned to a specific version, or (c) maintaining only very shallow patches. Direct frontend source modifications create merge conflicts on every upgrade, and there's no general-purpose component override or hook system to avoid this [[1]](https://github.com/apache/superset/discussions/39019#discussioncomment-16417003).
**What's actually available without forking:**
- **Extensions Registry** — lets you inject custom React components at a few specific points (`welcome.banner`, `welcome.message`, `navbar.right`), but it doesn't cover FilterBar behavior [[2]](https://github.com/apache/superset/discussions/40362#discussioncomment-17156883)
- **`FLASK_APP_MUTATOR`** — powerful for backend logic injection via `superset_config.py`, but doesn't help with frontend UX [[1]](https://github.com/apache/superset/discussions/39019#discussioncomment-16417003) [[3]](https://github.com/apache/superset/discussions/39019)
- **CSS/theming** — good for visual tweaks, not behavioral changes [[4]](https://github.com/apache/superset/discussions/39321#discussioncomment-16540605)
**For auto-apply filters specifically:** This is a recognized extensibility gap. The "Apply" button behavior was intentional but is being reconsidered based on community feedback [[5]](https://github.com/apache/superset/issues/36876). There's no configuration path to change it today.
**If you must patch frontend code, some strategies to minimize pain:**
1. **Keep patches minimal and isolated** — touch as few files as possible, ideally only the specific component logic (e.g., the FilterBar apply handler)
2. **Use git rebase workflow** — rebase your branch on upstream tags rather than merging; this surfaces conflicts early and keeps history clean
3. **Pin to stable release tags** — don't track `master`; upgrade deliberately between tagged releases
4. **Separate your changes into atomic commits** — makes it easier to re-apply patches after resolving conflicts
5. **Track upstream issues** — the auto-apply filter request ([#37069](https://github.com/apache/superset/issues/37069)) may eventually land upstream, eliminating the need for your patch
**A potentially cleaner alternative for filters:** There's a community-discussed approach of building custom filter components as custom charts using native cross-filtering [[6]](https://github.com/apache/superset/discussions/40822). This removes you from the FilterBar code entirely and places filter controls anywhere on the dashboard canvas — worth exploring if it fits your UX goals.
The reality is that for one or two targeted behavioral changes, a thin fork with minimal, well-isolated patches is what most teams end up doing. It's not ideal, but it's manageable if you treat those patches as temporary until upstream catches up.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apache%2Fsuperset).*
---
Share context across your team and agents. Try [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-tagline&utm_term=apache%2Fsuperset).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-feedback&utm_term=apache%2Fsuperset&message_id=e606587b-7b33-4f8c-92fa-01aa6e63269e) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-learn-repo&utm_term=apache%2Fsuperset) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-add-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/41185#discussioncomment-17348221
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org