MAIDR JavaScript API
    Preparing search index...

    Interface D3HeatmapConfig

    Configuration for binding a D3 heatmap.

    interface D3HeatmapConfig {
        id?: string;
        title?: string;
        subtitle?: string;
        caption?: string;
        axes?: { x?: D3AxisInput; y?: D3AxisInput; fill?: D3AxisInput };
        format?: AxisFormat;
        autoApply?: boolean;
        selector: string;
        x?: DataAccessor<string>;
        y?: DataAccessor<string>;
        value?: DataAccessor<number>;
        yOrder?: string[];
        xOrder?: string[];
    }

    Hierarchy (View Summary)

    Index

    Properties

    id?: string

    Unique identifier for the chart. Used as the MAIDR id.

    title?: string

    Chart title displayed in text descriptions.

    subtitle?: string

    Chart subtitle.

    caption?: string

    Chart caption.

    axes?: { x?: D3AxisInput; y?: D3AxisInput; fill?: D3AxisInput }

    Axis configuration. Each axis may be provided as either a plain string (shorthand for { label: value }) or a full AxisConfig object (for per-axis format, or grid navigation on scatter).

    For heatmaps and segmented bar charts, use fill for the color/category axis; the binder maps it to the canonical z axis in the MAIDR schema.

    Type Declaration

    format?: AxisFormat

    Optional formatting configuration applied to axes that do not specify their own format. Per-axis format on AxisConfig takes precedence.

    autoApply?: boolean

    When true (the default), the binder writes the generated MAIDR schema to the SVG as a maidr-data attribute so vanilla-JS users don't need to call svg.setAttribute(...) themselves. The returned result is unchanged either way.

    Set to false if you are driving MAIDR yourself — e.g. passing the returned schema to <Maidr data={...}> or persisting it elsewhere. The React adapter (useD3Adapter, MaidrD3) forces this to false internally so it can stay in control of the schema.

    true
    
    selector: string

    CSS selector for the cell elements (e.g., 'rect.cell', 'rect').

    x?: DataAccessor<string>

    Accessor for the x-axis category value.

    'x'
    
    y?: DataAccessor<string>

    Accessor for the y-axis category value.

    'y'
    
    value?: DataAccessor<number>

    Accessor for the cell value.

    'value'
    
    yOrder?: string[]

    The row labels top-first, in the order the chart draws them.

    Supply it whenever the join does not already iterate the rows top-down: usually yScale.domain(), or its reverse for a band scale whose domain ascends up the page. Without it the rows are taken in order of appearance in the DOM, which is the order the join happened to run in and need not be the order anything is drawn in (#978).

    Getting it wrong is silent — a matrix of numbers looks the same either way up — and what goes wrong is the reader's model of the chart rather than any value: walks down a chart whose rows arrived bottom-first, and the cursor enters at the top corner instead of the bottom.

    Labels the cells do not carry are ignored, and an order that does not name every row is declined in favour of appearance order rather than dropping a row the chart draws.

    xOrder?: string[]

    The column labels in the order the chart draws them, left first — usually xScale.domain(), or its reverse for a band scale that runs the other way. Without it the columns are taken in order of appearance in the DOM, which is the order the join happened to run in and need not be the order anything is drawn in (#1013).

    The same reasoning as D3HeatmapConfig.yOrder, and the same silence when it is wrong — what suffers is the reader's model of the chart rather than any value, with walking left along a grid whose columns arrived right-first.

    Labels the cells do not carry are ignored, and an order that does not name every column is declined in favour of appearance order rather than dropping a column the chart draws.