Fixing Superset’s Grid Engine to Build Asymmetric Dashboards

by

Summary

During a production dashboard migration, we identified a recurring friction point in Apache Superset’s layout engine. Users frequently attempt to create asymmetric, non-grid-aligned layouts (e.g., a vertical stack of two charts next to a single tall chart). The built-in drag-and-drop UI is strictly optimized for a row-based grid system, which makes complex, non-uniform layouts difficult to achieve through the standard visual editor.

Root Cause

The core issue stems from the underlying Grid Layout Engine used by Superset, which is based on a row-centric coordinate system.

  • Row-First Constraint: The UI is designed to prioritize horizontal placement within a defined row.
  • Container Hierarchy: The editor manages elements via Row and Column components, but the visual drag-and-drop interface often forces components into the next available horizontal slot rather than allowing free-form vertical spanning.
  • Z-Index and Coordinate Mapping: While the underlying JSON metadata supports specific x, y, w, and h (width/height) coordinates, the visual abstraction layer in the UI limits the user’s ability to set these precise values manually.

Why This Happens in Real Systems

In large-scale enterprise platforms, there is often a trade-off between flexibility and usability.

  • Standardization vs. Freedom: Developers build “constrained editors” to prevent users from creating broken or non-responsive layouts. By forcing a grid, the system ensures that dashboards remain somewhat readable across different screen sizes.
  • State Management Complexity: Allowing “free-form” placement requires the system to manage a much more complex state where every single element has absolute positioning, which is a nightmare for responsive design and mobile viewing.
  • Abstraction Leaks: The UI is an abstraction of a more complex JSON Metadata schema. When the UI doesn’t support a specific feature (like complex vertical spanning), it is perceived as a system limitation, even if the backend supports it.

Real-World Impact

  • Reduced Developer Velocity: Data engineers spend hours fighting the UI instead of building meaningful visualizations.
  • Poor UX/UI Quality: Stakeholders receive dashboards that look “clunky” or unpolished because the layout doesn’t follow modern design principles.
  • Maintenance Overhead: When users attempt to “hack” layouts using multiple nested rows, the JSON metadata becomes bloated and difficult to debug or programmatically update.

Example or Code

To achieve the layout | A | C | over | B | |, you must bypass the UI and manipulate the Dashboard JSON Metadata directly. You need to define the position_json where Chart C has a height (h) that spans the sum of A and B.

{
  "gridCoord": {
    "CHART_A": { "x": 0, "y": 0, "w": 6, "h": 4 },
    "CHART_B": { "x": 0, "y": 4, "w": 6, "h": 4 },
    "CHART_C": { "x": 6, "y": 0, "w": 6, "h": 8 }
  }
}

How Senior Engineers Fix It

A senior engineer doesn’t just “try harder” with the UI; they look for the source of truth.

  1. Metadata Manipulation: Instead of fighting the drag-and-drop, we go to the “Edit Dashboard” -> “Edit Properties” -> “JSON Metadata” section.
  2. Coordinate Mapping: We manually calculate the x, y, w, and h values. To get the desired effect, we ensure Chart C’s y starts at the same point as Chart A, but its h (height) is equal to A.h + B.h.
  3. Component Nesting: If the JSON is too complex, we use the Layout Components (Tabs and Rows) strategically. To achieve asymmetric layouts, we often wrap charts in a Row component first, and then use Column components within that row to create the vertical split.
  4. Template Validation: We treat the JSON metadata as Infrastructure as Code (IaC), validating the coordinate math before saving to prevent dashboard corruption.

Why Juniors Miss It

  • UI Dependency: Juniors often assume that if the UI doesn’t allow it, the system cannot do it. They lack the intuition to look under the hood at the underlying data structure.
  • Lack of Mathematical Modeling: They try to “nudge” elements visually, whereas a senior engineer treats the layout as a 2D coordinate system problem.
  • Tooling Tunnel Vision: They focus on the “Editor” tool rather than the “Metadata” schema that drives the editor.

Leave a Comment