# Migration

<a name="28.0.0"></a>

## 28.0.0

### React 18 Upgrade

The codebase has been upgraded from React 16 to React 18.

**Breaking Changes:**

- All packages now require React 18 as a peer dependency.
- If your application or library is still using React 16, you must upgrade to React 18 to use these packages.
- Some APIs and lifecycle methods deprecated in React 18 may no longer work as expected.
- Older frameworks like Enzyme don’t support React 18, so unit tests should be migrated to RTL or another compatible framework.
- If you use third-party libraries, ensure they are compatible with React 18.

**Migration Steps:**

1. Upgrade your project’s `react` and `react-dom` dependencies to version 18.
2. Review your code for usage of deprecated lifecycle methods and update as needed.
3. Test your application thoroughly for any changes in rendering or behavior.

### SUI5 Upgrade

The codebase has been upgrade from SUI4 to SUI5.

#### SUI 5 Upgrade Summary

Splunk UI 5 (SUI5) introduces a unified design system with significant improvements and some breaking changes. Key updates include:

- **Consistent Spacing:** Margin has been removed from all components to ensure consistent layouts. Use the new `Layout` component or layout mixins for spacing between elements.
- **Typography Updates:** Font sizes, weights, and families are now managed through new mixins, and font size no longer changes with density.
- **Accessibility Improvements:** Disabled components now use a more accessible "dimmed" state by default, and various props have been updated or removed to improve accessibility and consistency.
- **Visual and Theming Changes:** Updated color palettes, background colors, and visual tokens to align with the new design system.

For detailed list of changes, see the [SUI5 Migration Guide](https://splunkui.splunk.com/Packages/react-ui/Migration).

#### Visual Changes

- Axis colors, text colors, and background colors have been updated to align with the new design system in SUI 5.
- You may notice differences in chart appearance, including:
    - Updated axis and gridline colors
    - New default background colors for charts and tables
    - Refreshed text colors for improved accessibility
    - Enterprise primary color now green
- If your application overrides these styles, review and update your customizations as needed.

**List of visual changes:**

- diffs are in the order of: before (left) | after (right)
- split snapshots order: top (enterprise light) | middle (enterprise dark) | bottom (prisma dark)

- All visualizations default background color for Prisma Dark theme updated to `#1a1c20`.

![All Visualizations - Prisma dark - Default background color](./src/common/docs/migrations/assets/defaultbackgroundcolor-diff.png)

- Info/Warning icon updated.

![Info icon - before](./src/common/docs/migrations/assets/info-before.png)
![Info icon - after](./src/common/docs/migrations/assets/info-after.png)

- No Datasource icon updated.

![No Datasource icon - before](./src/common/docs/migrations/assets/nodatasource-before.png)
![No Datasource icon - after](./src/common/docs/migrations/assets/nodatasource-after.png)

- Events multiple elements updated.
    - pagination spacing and focus color updated for enterprise.
    - alternating table background color updated due to SUI5 upgrade.
    - link styling updated.
    - header and paginator container spacing updated.

![Events - before](./src/common/docs/migrations/assets/eventsviz-before.png)
![Events - after](./src/common/docs/migrations/assets/eventsviz-after.png)

- Events time control popover colors, size, and spacing updated.

![Events time control popover dark - diff](./src/common/docs/migrations/assets/events-timecontrolpopover-dark-diff.png)
![Events time control popover light - diff](./src/common/docs/migrations/assets/events-timecontrolpopover-light-diff.png)

- EventsViewer multiple elements updated.
    - alternating table background color updated due to SUI5 upgrade.
    - text color updated.
    - text highlight color updated.
    - border color of separate entries in expanded row updated.

![EventsViewer - before](./src/common/docs/migrations/assets/eventsviewer-before.png)
![EventsViewer - after](./src/common/docs/migrations/assets/eventsviewer-after.png)

- FieldSummary bar colors and dropdown select button colors updated.

![FieldSummary enterprise - diff](./src/common/docs/migrations/assets/fieldsummary-enterprise-diff.png)
![FieldSummary prisma - before](./src/common/docs/migrations/assets/fieldsummary-before.png)
![FieldSummary prisma - after](./src/common/docs/migrations/assets/fieldsummary-after.png)

- LinkGraph default node background color updated.

![LinkGraph node color](./src/common/docs/migrations/assets/linkgraph-before.png)
![LinkGraph node color](./src/common/docs/migrations/assets/linkgraph-after.png)

- Map tooltip spacing and background color Dark updated.

![Map tooltip - before](./src/common/docs/migrations/assets/map-tooltip-before.png)
![Map tooltip - after](./src/common/docs/migrations/assets/map-tooltip-after.png)

- Markdown spacing updated.

![Markdown - before](./src/common/docs/migrations/assets/markdown-before.png)
![Markdown - after](./src/common/docs/migrations/assets/markdown-after.png)

- Punchcard bubble default text color auto selects white or black based on luminance calculated with bubble color, bubble opacity, and background color to meet WCAG contrast requirements.
- Punchcard gridlines updated.

![Punchcard - before](./src/common/docs/migrations/assets/punchcard-before.png)
![Punchcard - after](./src/common/docs/migrations/assets/punchcard-after.png)

- Table multiple elements updated.
    - Sort by icon updated.
    - Header dividers color updated.
    - Pagination focus color updated for enterprise.

![Table - before](./src/common/docs/migrations/assets/table-before.png)
![Table - after](./src/common/docs/migrations/assets/table-after.png)

- Timeline axis border and text colors updated.

![Timeline - before](./src/common/docs/migrations/assets/timeline-before.png)
![Timeline - after](./src/common/docs/migrations/assets/timeline-after.png)

<a name="27.0.0"></a>

## 27.0.0

Deprecated packages `@splunk/dashboard-visualizations`, `@splunk/react-visualizations` and `@splunk/visualization-encoding-parsers` have been removed.

<a name="26.4.1"></a>

## 26.4.1

The default formatting for time values in Table has been reverted, no formatting will be applied by default.

<a name="26.4.0"></a>

## 26.4.0

The default formatting for time values in Table has been changed to YYYY-MM-DD HH:mm:ss

<a name="26.0.0"></a>

## 26.0.0

1. @splunk/charting dependency upgraded to v2.0.0 which has Highcharts v9 upgrade. This has visual and DOM rendering differences for charting components.The consuming applications will see these visual changes. Also there are some DOM rendering changes wrt tooltips, the corresponding test cases need to be updated.

- Legend items have more spacing across all charts as part of legend item accessibility improvement in Highcharts

![Legend items difference](./src/common/docs/migrations/assets/render-diff1.gif)

- On legend item hover, the gray color on inactive series is more pronounced, seems to be a good improvement for visibility

![Legend item hover difference](./src/common/docs/migrations/assets/render-diff2A.gif)

![Legend item hover difference](./src/common/docs/migrations/assets/render-diff2B.gif)

- Bubble chart data point minor rendering difference

![Bubble chart difference](./src/common/docs/migrations/assets/render-diff3.gif)

- Line chart marker rendering minor difference

![Line chart maker difference](./src/common/docs/migrations/assets/render-diff4.gif)

- Slight shift up in the column/ bar charts with axis label rotated

![Column chart difference](./src/common/docs/migrations/assets/render-diff5.gif)

- Scatter chart low datapoints showing full square aligning with the axis

![Scatter chart difference](./src/common/docs/migrations/assets/render-diff6.gif)

The consuming applications will see these visual changes. Also there are some DOM rendering changes wrt tooltips, the corresponding test cases need to be updated.

- `@splunk/highcharts-scaled-events` deprecated

`@splunk/highcharts-scaled-events` deprecated as the support of scale events and tooltip is supported in Highcharts v9 version

2. Single Value Radial's major value's dynamic color's "Match Value" is removed. Any pre-existing dashboard using "Match Value" can no longer be edited in the editor. Match value can only be edited in the source code. Clicking on "Customized in source" then "Reset to default" will remove any pre-existing "Match Value" data and change major value's dynamic color into a "Range Value" configuration (this will cause you to lose pre-existing "Match Value" data).

![Remove match value](./src/common/docs/migrations/assets/svr_remove_match_value.png)

To avoid losing pre-existing "Match Value" data, you can either edit the data in the source code. Or you can manually convert your pre-existing "Match Value" data into a "Range Value" configuration (recommended).

## 25.5.5

Visualization type Choropleth World (`viz.geojson.world`) and Choropleth USA (`viz.geojson.us`) will be deprecated and migrated to Map `splunk.map`

Old：Choropleth World (`viz.geojson.world`)

![Choropleth World `viz.geojson.world`](./src/common/docs/migrations/assets/viz.geojson.world.png)

New: Map (`splunk.map`)

![Map `splunk.map`](./src/common/docs/migrations/assets/splunk.map_world.png)

Old：Choropleth USA (`viz.geojson.us`)

![Choropleth USA `viz.geojson.us`](./src/common/docs/migrations/assets/viz.geojson.us.png)

New: Map (`splunk.map`)

![Map `splunk.map`](./src/common/docs/migrations/assets/splunk.map_us.png)

## 25.0.0

### Add support to space in field names

`overlayFields` and `Column.y2Fields` now support space inside the names of fields (i.e. “top user”, “max all time”).

For example, Column Chart - `y2Fields: ['test name', 'another test name']`

Old:
![Column Chart - Overlay Field with space specified in field names](./src/common/docs/migrations/assets/columncharty2fieldsold.png)

New:
![Column Chart - Overlay Field with space specified in field names](./src/common/docs/migrations/assets/columncharty2fieldsnew.png)

<br />

### Axes charts editing UI

Axes charts (Area/Bar/Bubble/Column/Line/Scatter) now expose the configuration UI for most options and regroups the editors in new panels. Please expect editor snapshot changes.

<br />

### Infer data type from the search result meta data fields - `type`, if present

There are a few indicators in the search meta data (apart from `_time` field) that can help infer on data type information:

- `type` field

    When search result fields are coerced into a different type, the search result meta data will include a `type` field

    Example

    ```js
        | eval foo = tostring(some_numeric_field) | table foo

        {
            name: 'foo',
            type: 'str'
        }
    ```

As a result, if we had `eval productId=tostring(12345)`, the visualization will treat **12345** as a `string` and dynamic coloring formatters like `rangeValue()` will not work as they require a `number` data type

<br />

### Visualization displays the original data value, and we move type coercion to the formatters

Previously, we used to coerce data into the inferred data type and, in the process, lost useful formatting context coming from a search result. We've updated this behavior to allow visualizations to directly render the data passed down, and moved type coercion into the DSL formatters.

For example, if the timestamp passed to us is `2020-09-02T09:09:36`, the visualization will display `2020-09-02T09:09:36` instead of `2020-09-02T09:09:36+00:00` (previous behavior)

<br />

### Update the data type inference algorithm to be more robust and handle mixed data types and `NULL` values

Type prioritization

Previously the type inference for a dataseries was performed by using a very basic method, basically compare the `first`, `mid` and `end` datavalue's types and return the majority type.

We've updated this inference technique to more robust method, instead of comparing just the `first`, `mid` and `end` datavalue's types, we create a map of actual count of each type in the data series. If only a single type exists in a dataseries, then that `type` will be returned as the inferred type. If more than one type exist, then type will be returned based on the prioritization rule `geojson > sparkline > array > string > color > number > time > null > unknown`. Empty strings ('') will be typed as unknown.

DSL selectors based on type `seriesByType`, `seriesByTypes`, `frameBySeriesTypes` and `seriesByPrioritizedTypes` are impacted. Viz's using these dsl selectors may return a different series now based on new type matching if the dataset has mixed types.

    Example
    Type inference update for data series

    Old
    ['1','2','3','4','5','6','7','8','9','10'] // => type inferred as 'number'
    [null,'2','3','4','5','6','7','8','9', null] // => type inferred as 'null'
    ['200','201','400','success','failure'] // => type inferred as 'number'
    ['','',''] // => type inferred as 'string'
    ['1','',''] // => type inferred as 'string'


    New
    ['1','2','3','4','5','6','7','8','9','10'] // => type inferred as 'number', all values 'number' type
    [null,'2','3','4','5','6','7','8','9',null] // => type inferred as 'number', mixed type values (number & null), based on priority 'number' > 'null'
    ['200','201','400','success','failure'] // => type inferred as 'string', mixed type values (number & string), based on priority 'string' > 'number'
    ['','',''] // => type inferred as 'unknown', all values 'unknown' type
    ['1','',''] // => type inferred as 'number', mixed type values (number & unknown), based on priority 'number' > 'string',

<a name="24.0.0"></a>

## 24.0.0

### SingleValueRadial design and option updates

SingleValueRadial is updated with new designs and options.
A list of SingleValueRadial's options have been updated such as `majorValue`, `trendValue`, `majorColor`, `trendColor`, `majorValueField`, `trendIndicatorPosition` (removed), and `maxValue` (added). See the [documentation page](https://eng-docs.splunkeng.com/visualizations/24.0.0/?path=%2FSingleValueRadial) for the new design, updated option names, types, and default values.

The `viz.singlevalueradial` to `splunk.singlevalueradial` conversion script has also been implemented to account for the updates. For example, if the `trendIndicatorPosition` is configured in `viz.singlevalueradial`, it will be automatically removed in `splunk.singlevalueradial`. And the default `majorValue` and `trendValue` will be preserved in the converted `splunk.singlevalueradial`.

Example:

```jsx
import React from 'react';
import SingleValueRadial from '@splunk/visualizations/SingleValueRadial';

export default () => (
    <SingleValueRadial
        options={{
            majorValue: '> primary | seriesByName("bar") | lastPoint()', // Specify the dataSource applied to the major value.
            trendValue: '> primary | seriesByName("bar") | delta(-2)', // Specify the dataSource applied to the trend value.
            maxValue: 1000, // Specify the value the radial fills up to.
            backgroundColor: '#aaaaff',
        }}
        dataSources={{
            primary: {
                data: {
                    columns: [
                        ['1', '62', '103', '308', '587', '876', '70', '80'],
                        ['1', '2', '3', '4', '5', '6', '7', '3200'],
                    ],
                    fields: [
                        {
                            name: 'foo',
                        },
                        {
                            name: 'bar',
                        },
                    ],
                },
                meta: {},
            },
        }}
    />
);
```

### FillerGauge default gaugeColor update

`splunk.fillergauge`'s default `gaugeColor` is updated to `#7B56DB`.
The `viz.fillergauge` to `splunk.fillergauge` conversion script has taken into account for this change.

Example:

```jsx
import React from 'react';
import FillerGauge from '@splunk/visualizations/FillerGauge';

export default () => (
    <FillerGauge
        options={{
            gaugeColor: '> value | rangeValue(gaugeColorRangeValueContext)', // viz.fillergauge default
            value: 123,
        }}
        context={{
            gaugeColorRangeValueContext: [
                {
                    from: 70,
                    to: 210,
                    value: '#ff7152',
                },
                {
                    from: 50,
                    to: 70,
                    value: '#fc9850',
                },
                {
                    from: 30,
                    to: 50,
                    value: '#f4df7a',
                },
                {
                    from: 20,
                    to: 30,
                    value: '#4beba8',
                },
                {
                    from: 0,
                    to: 20,
                    value: '#5fbcff',
                },
            ],
        }}
        dataSources={{
            primary: {
                requestParams: { offset: 0, count: 20 },
                data: {
                    fields: [{ name: 'count' }],
                    columns: [['78']],
                },
                meta: { totalCount: 200 },
            },
        }}
    />
);
```

### Pie chart option renames

`seriesColorsByValue` was previously used for specifying field colors in a Pie visualization. This option has been renamed to `seriesColorsByField`. No functionality has been changed other than the rename.

The `viz.pie` to `splunk.pie` conversion script has also been modified to account for this rename.

```jsx
import React from 'react';
import Pie from '@splunk/visualizations/Pie';

export default () => (
    <Pie
        options={{ seriesColorsByField: { December: '#008000', May: '#FF0000' } }} // was previously seriesColorsByValue
        dataSources={{
            primary: {
                requestParams: { offset: 0, count: 20 },
                data: {
                    fields: [{ name: 'component' }, { name: 'count' }],
                    columns: [
                        [
                            'January',
                            'February',
                            'March',
                            'April',
                            'May',
                            'June',
                            'July',
                            'August',
                            'September',
                            'October',
                            'November',
                            'December',
                        ],
                        ['1', '1', '1', '2', '10', '10', '5', '5', '5', '5', '5', '50'],
                    ],
                },
                meta: { totalCount: 20 },
            },
        }}
    />
);
```

<a name="23.0.0"></a>

## 23.0.0

### onEventTrigger and hasEventHandler flag

Previously, ChoroplethSVG, SingleValue (SV, SVI, and SVR), and shape (Ellipse + Rectangle) visualizations were the only visualizations to require a `hasEventHandler` flag for their respective event callback handlers to be invoked when an event occurred. As such, charting-based visualizations were the only exception to this invocation pattern.

e.g.

```jsx
import React from 'react';
import SingleValue from '@splunk/visualizations/SingleValue';

export default () => (
    <SingleValue
        options={{
            unit: '$',
            unitPosition: 'before',
        }}
        hasEventHandlers
        onEventTrigger={(...ev) => console.log(ev)}
        dataSources={{
            primary: {
                data: {
                    columns: [
                        ['1', '62', '103', '308', '587', '876', '930', '1320'],
                        [
                            '2018-08-19T00:00:00.000+00:00',
                            '2018-08-20T00:00:00.000+00:00',
                            '2018-08-21T00:00:00.000+00:00',
                            '2018-08-22T00:00:00.000+00:00',
                            '2018-08-23T00:00:00.000+00:00',
                            '2018-08-24T00:00:00.000+00:00',
                            '2018-08-25T00:00:00.000+00:00',
                            '2018-08-26T00:00:00.000+00:00',
                        ],
                    ],
                    fields: [
                        {
                            name: 'foo',
                        },
                        {
                            name: '_time',
                        },
                    ],
                },
                meta: {},
            },
        }}
    />
);
```

The `hasEventHandlers` flag has now been extended to charting-based visualizations as well.

```jsx
import React from 'react';
import Area from '@splunk/visualizations/Area';

export default () => (
    <Area
        options={{}}
        hasEventHandlers
        onEventTrigger={(...ev) => console.log(ev)}
        dataSources={{
            primary: {
                requestParams: { offset: 0, count: 20 },
                data: {
                    fields: [
                        {
                            name: 'sourcetype',
                        },
                        {
                            name: 'count',
                            type_special: 'count',
                        },
                        {
                            name: 'percent',
                            type_special: 'percent',
                        },
                    ],
                    columns: [
                        [
                            'splunkd',
                            'splunkd_ui_access',
                            'splunkd_access',
                            'splunk_web_access',
                            'scheduler',
                            'splunk_web_service',
                        ],
                        ['600', '525', '295', '213', '122', '19'],
                        ['87.966380', '50.381304', '60.023780', '121.183272', '70.250513', '90.194752'],
                    ],
                },
                meta: { totalCount: 100 },
            },
        }}
    />
);
```

### Event Payload Changes

To support consistency in event payloads, name, value, and `row.<fieldname>.value` have been uniformly applied to refer to the datasource field name, the corresponding value for the datapoint, and the corresponding value in the specified field for the datapoint row for which an interaction was triggered respectively (when applicable). Payload keys which contained duplicate information were removed. Moving forward, UDF will support these as tokens available in dashboards. For additional background information, refer to the [Viz epic](https://jira.splunk.com/browse/SCP-42105) and [UDF epic](https://jira.splunk.com/browse/SCP-39586).

Note: Not all visualizations, such as Single Value, support `row.<fieldname>.value`

#### Charting-based visualizations event payload changes

In addition to the changes mentioned above, it should be noted that `name2` and `value2` have been removed from charting-based platform visualizations, with `name` and `value` taking on values that were previously held by `name2` and `value2`. This corresponds to the y-fieldname and y-value for the datapoint that was interacted with. Additionally, the `rowContext` field has been flattened by adhering to a consistent `row.<fieldName>.value` structure.

Previous charting-viz event payloads:

```js
{
    type: "point.mouseout",
    originalEvent: "...Original Event instance...",
    payload: {
        name: "_time",
        value: "1525310146.000",
        name2: "count",
        value2: "2",
        _span: 1,
        rowContext: {
            "row._time": "1525310146.000",
            "row.count": "2"
        },
        tooltipContext: {
            tooltipX: 204.3,
            tooltipY: 166.86666666666667
        }
    }
}
```

Updated event payloads

```js
{
    type: "point.mouseout",
    originalEvent: "...Original Event instance...",
    payload: {
        _span: 1,
        tooltipContext: {
            tooltipX: 204.3,
            tooltipY: 166.86666666666667
        },
        name: "count", // refers to the y-field
        value: "2", // refers to the y-value
        "row._time.value": "1525310146.000",
        "row.count.value": "2"
    }
}
```

#### ChoroplethSVG event payload changes

`dataName` and `dataValue` have been renamed to `name` and `value`.

Previous area.click payload:

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        clientX: 940,
        clientY: 453,
        dataValue: "10000",
        dataName: "ATX-270-B"
    },
    type: "area.click"
}
```

New area.click payload:

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        clientX: 940,
        clientY: 453,
        value: "10000",
        name: "ATX-270-B"
    },
    type: "area.click"
}
```

#### SingleValue event payload changes

`majorValue` has been renamed to `value`, and `name` has been added to the payload.

Previous value.click payload:

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        majorValue: 1320,
        trendValue: 390
    },
    type: "value.click"
}
```

New value.click payload

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        trendValue: 390,
        value: 1320,
        name: "foo"
    },
    type: "value.click"
}
```

#### Table event payload changes

Similarly to charting-based visualizations, the `row` payloads have been flattened using the `row.<fieldName>.value` structure. Consequently, `rowValues` has been removed to avoid duplicating information already contained in the flattened structure. `name` and `value` are added to establish consistency with other event payloads emitted by other visualizations.

Previous cell.click payload:

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        cellIndex: 0,
        rowIndex: 0,
        fieldValue: "sourcetype",
        cellValue: "splunkd",
        cellRawValue: "splunkd",
        rowValues: [
            "splunkd",
            500,
            [
                "/opt1/dev",
                "/opt1/qa",
                "/root"
            ],
            [
                "##__SPARKLINE__##",
                38.41707347607988,
                89.761764861815,
                21.557911515120654,
            ]
        ],
        value: "splunkd",
        name: "sourcetype",
        row: {
            #: {
                value: 1
            },
            sourcetype: {
                value: "splunkd"
            },
            count: {
                value: 500
            },
            values(source): {
                value: [
                    "/opt1/dev",
                    "/opt1/qa",
                    "/root"
                ]
            },
            sparkline: {
                value: [
                    "##__SPARKLINE__##",
                    38.41707347607988,
                    89.761764861815,
                    21.557911515120654,
                ]
            }
        }
    },
    type: "cell.click"
}
```

New payload structure:

```js
{
    originalEvent: "...Original Event instance...",
    payload: {
        cellIndex: 0,
        rowIndex: 0,
        fieldValue: "sourcetype",
        cellValue: "splunkd",
        cellRawValue: "splunkd",
        value: "splunkd",
        name: "sourcetype",
        "row.#.value": 1,
        "row.sourcetype.value": "splunkd",
        "row.count.value": 500,
        "row.values(source).value": [
            "/opt1/dev",
            "/opt1/qa",
            "/root"
        ],
        "row.sparkline.value": [
            "##__SPARKLINE__##",
            38.41707347607988,
            89.761764861815,
            21.557911515120654,
        ]
    },
    type: "cell.click"
}
```

<a name="22.0.0"></a>

## 22.0.0

### Peer dependency changes

- `@splunk/dashboard-visualizations`, `@splunk/react-visualizations` `@splunk/visualization-editors` and `@splunk/visualizations` now have styled-components@^5.1 as a peer dependency (was previously ^3 || ^4)
- `@splunk/react-ui` is no longer a required peer dependency (it's bundled as a direct dependency in vision packages)

### Theming changes in visualizations

With the SUI 4.0 uptake (@splunk/react-ui@^4, @splunk/themes@^0.7.0), visualizations and editors no longer export their own themes. Instead, themes are consolidated as part of the visualization directly.
If no `<SplunkThemeProvider>` is specified, visualizations will default to using their prisma dark theme configuration. Previously, visualizations defaulted to enterprise light if no theming information was given.

Previous usage:

```jsx
import React from 'react';
import { ThemeProvider } from 'styled-components';
import SingleValue, { themes as SingleValueThemes } from '@splunk/visualizations/SingleValue';

// ...

export const MyComponent = props => (
  <ThemeProvider theme={SingleValueThemes}>
    <SingleValue {...props}>
  </ThemeProvider>
);
```

**New usage with SUI4**:

```jsx
import React from 'react';
import SplunkThemeProvider from '@splunk/themes/SplunkThemeProvider';
import SingleValue from '@splunk/visualizations/SingleValue';

// ...

export const MyComponent = props => (
  <SplunkThemeProvider family="prisma" colorScheme="dark" density="comfortable">
    <SingleValue {...props}>
  </SplunkThemeProvider>
);
```

### Inferring themed default values for editors

The editorConfig for DynamicEditor has a new `pickForTheme` editorProp for displaying themed default values in editors.

```js
const config = {
    label: _('Font'),
    layout: [
        [
            {
                label: _('Header Text Color'),
                option: 'headerTextColor',
                editor: 'editor.color',
                editorProps: {
                    pickFromTheme: theme =>
                        pick({
                            enterprise: variables.textColor,
                            prisma: {
                                light: variables.contentColorDefault,
                                dark: variables.neutral500,
                            },
                        })({ theme }),
                },
            },
        ],
    ],
};
```

However, the `themeVariable` editorProp can be used if the theme variable name exists in all SUI themes. This is most often used for prisma theme variables that have corresponding enterprise aliases.
Example usage:

```jsx
const config = {
    label: _('Font'),
    layout: [
        [
            {
                label: _('Header Text Color'),
                option: 'headerTextColor',
                editor: 'editor.color',
                editorProps: {
                    // for the color editor, this would display #3c444d in enterprise light, #ffffff in enterprise dark, and rgba(255, 255, 255, 0.7) in prisma dark.
                    themeVariable: 'contentColorDefault',
                },
            },
        ],
    ],
};
```

For more complex use cases which require editors to infer theme defaults from DSL, a `themes` object which denotes key-value pairs of functions that return resolved values (hence the `variables.color(props)` invocation) must be specified.

```jsx
const themes = {
    defaultFontColor: props =>
        pick({
            enterprise: {
                dark: variables.textColor(props),
                light: variables.gray20(props),
            },
            prisma: variables.contentColorActive(props),
        })(props),
    defaultBlockFontColor: props =>
        pick({
            enterprise: variables.white(props),
            prisma: variables.contentColorActive(props),
        })(props),
};
const config = {
    label: _('Major Color'),
    layout: [
        [
            {
                label: _('Major Color'),
                option: 'majorColor',
                editor: 'editor.color',
                // in this example, majorColor would have a default of `> themes.defaultFontColor` or `themes.defaultBlockFontColor`
                // DSL needs to receive a function that returns a resolved theme value
                editorProps: {
                    themes,
                },
            },
        ],
    ],
};
```

See https://cd.splunkdev.com/devplat/vision/-/merge_requests/1213#approach for a background regarding this approach.

### Other visual changes

- visualizations in enterpriseDark use `#000000` for their background color, and `#0b0c0e` for their background color in prisma dark. `#ffffff` is still used as the background color in enterprise light

- various minor theming changes for prisma dark (which was previously SCP) theme for visualizations and corresponding editors

- Updated Single Value's sparkline area opacity from 75% to 20%. This causes the background color to shine through more prominently ( see [previous](https://cd.splunkdev.com/devplat/vision/-/blob/319742c672cd29f0a9c650cba7b6a08ef5604733/packages/dashboard-visualizations/tests/__image_snapshots__/visual-test-js-dashboard-visualizations-dashboard-single-value-encoding-fill-format-specified-sparkline-area-true-fill-color-red-1-snap.png) vs [new](https://cd.splunkdev.com/devplat/vision/-/blob/32dc99a9f2da52d17b244f0be2081760a2c2ae04/packages/dashboard-visualizations/tests/__image_snapshots__/visual-test-js-dashboard-visualizations-dashboard-single-value-encoding-fill-format-specified-sparkline-area-true-fill-color-red-1-snap.png) )

<a name="21.0.0"></a>

## 21.0.0

- Renamed the following options in @splunk/visualizations for SingleValue, SingleValueIcon and SingleValueRadial:

    | previous option naming     | new option naming            |
    | -------------------------- | ---------------------------- |
    | `deltaValue`               | `trendValue`                 |
    | `deltaColor`               | `trendColor`                 |
    | `deltaFontSize`            | `trendFontSize`              |
    | `shouldTruncateDeltaValue` | `shouldAbbreviateTrendValue` |
    | `deltaDisplayMode`         | `trendDisplayMode`           |

<a name="19.0.0"></a>

## 19.0.0

No API changes.

Visual changes related to Highcharts v7.2.1 upgrade can be summarized as

### Major

- Axes are stretched to take up more space
  ![Axes Stretched](./src/common/docs/migrations/assets/axesstretch.png)

- Displays the last label on a categorical axes
  ![Category Label](./src/common/docs/migrations/assets/categoricallabel.png)

- Legends are spaced equally
  ![Legends](./src/common/docs/migrations/assets/legends.png)

- Pie Chart shows fewer labels when there are too many labels
  ![Piechart](./src/common/docs/migrations/assets/piechartlabel.png)

- Zooming a chart maintains parent axis
  ![Zoom](./src/common/docs/migrations/assets/zoom.png)

### Minor

- Colors of the chart grid have changed
- Minor pixel differences

### Known issues

- [SPL-190515](https://jira.splunk.com/browse/SPL-190515) Bubble chart fails to render when `axisY.maximumNumber` and `axisLabelsX.integerUnits` are set ([workaround](https://jira.splunk.com/browse/SPL-190515?focusedCommentId=4960319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-4960319))

For a detailed list of changes refer to [Splunk Charting upgrade review doc](https://docs.google.com/document/d/13GWdNsbLFvY_M824PsBokBfLbVFuyp4qRkaaT5syOUE/edit) or the [visual diffs](https://drive.google.com/drive/u/1/folders/0AGiuEeEGQemoUk9PVA)

### Deprecations

- @splunk/react-visualization/numberUtils is deprecated. Use @splunk/visualizations-shared/numberUtils instead.

<a name="18.0.0"></a>

## 18.0.0

- Support for `withError`, `withNoResultIndicator` and `withLoadingIndicator` higher order components (HOCs) has been dropped.
- Visualizations will no longer display Title or Description. `withTitleAndDescription` HOC has been replaced by `withBackgroundColor`. The `withBackgroundColor` HOC retains the logic to apply a background color to the container surrounding the visualization, and calculate pixel sizes for height and width when needed.

Usage Example

```js
withBackgroundColor({
    defaultBackgroundColor: themeRegistry.themeVariable('defaultBackgroundColor'),
    enableBackgroundColorOption: true,
})(Visualization);
```

<a name="17.0.0"></a>

## 17.0.0

- In Single Value visualization, support for option 'sparklineFillOpacity' has been dropped. A constant sparkline fill opacity of 0.05 is used.

- BaseVisualization received a new prop `onComputedProps`

The `onComputedProps` prop allows dashboard-visualizations to communicate calculated props (e.g. a background color that is calculated based on data) upwards to its consumer.

For the time being only Single Value and Single Value Radial make use of this callback to communicate a data driven background color to dashboards-framework.

Usage Example

```js
const TitleContainer = styled.div`
    background-color: ${props => props.backgroundColor};
`;
const DashboardWrapper = props => {
    const [state, setState] = useState({ backgroundColor: '#f00' });
    const { title, ...otherVizProps } = props;
    return (
        <>
            <TitleContainer backgroundColor={state.backgroundColor}>{title}</TitleContainer>
            <Visualization {...otherVizProps} onComputedProps={setState} />
        </>
    );
};
```

<a name="16.0.0"></a>

## 16.0.0

The Single Value delta colorization behavior changed:

1. Delta color is not affected by major color anymore
2. By default when using a fill/background, delta will use the block font color (white)
3. When using a default background, in all themes delta will be colored unless customized with encoding

If required, the old delta colorization behavior can be retained to some extent:

1: set delta color encoding to same as major color encoding

```
encoding={{
  majorColor: {
    field: 'primary[0]',
    format: {
      type: 'rangevalue',
      ranges: [{
        from: 0,
        value: '#fff',
      }, {
        to: 0,
        value: '#fff',
      }]
    },
  },
  // matching with major color
  deltaColor: {
    field: 'primary[0]',
    format: {
      type: 'rangevalue',
      ranges: [{
        from: 0,
        value: '#fff',
      }, {
        to: 0,
        value: '#fff',
      }]
    },
  }
}}
```

2 & 3: set a delta color encoding to translate to a color instead of falling back to the default

```
encoding={{
  //...
  // colorizes delta white
  deltaColor: {
    field: 'primary[0]',
    format: {
      type: 'rangevalue',
      ranges: [{
        from: 0,
        value: '#fff',
      }, {
        to: 0,
        value: '#fff',
      }]
    },
  }
}}
```

<a name="15.6.0"></a>

## 15.6.0

ChoroplethSvg remote URL input are now disabled by default. Please set the feature flag enableSvgHttpDownloader to true to enable http and https downloads.

<a name="15.4.0"></a>

## 15.4.0

Please update your dependencies for the following packages to match peerDependency requirements:

- @splunk/react-ui@^2.16.0
- @splunk/themes@^0.4.2

<a name="15.3.0"></a>

## 15.3.0

Standardize the format of visualization options that expect an 'array' or 'object', but are inputted as 'string'.
The option type 'string' for the following has been deprecated:

- seriesColors, legend.labels, data.fieldShowList, data.fieldHideList, gaugeColors, chart.rangeValues ('string' -> 'array')
- fieldColors, annotation.categoryColors, fieldDashStyles ('string' -> 'object'),

Before

```
option={{
  seriesColors: '[0x0000F, 0x00001]',
  'legend.labels': '[foo, bar]',
  'data.fieldShowList': '[percent, count]',
  'data.fieldHideList': '[percent, count]',
  gaugeColors: '[0x0000F, 0x00001]',
  'chart.rangeValues': '[1, 23]',
  fieldColors: '{"count": 0x008000, "percent": 0xFFA500}',
  'annotation.categoryColors': '{"count": 0x008000, "percent": 0xFFA500}',
  fieldDashStyles: '{"count": shortDash, "percent": dotDash}',
}}
```

After

```
option={{
  seriesColors: ['0x0000F', '0x00001'],
  'legend.labels': ['foo', 'bar'],
  'data.fieldShowList': ['percent', 'count'],
  'data.fieldHideList': ['percent', 'count'],
  gaugeColors: ['0x0000F', '0x00001'],
  'chart.rangeValues': [1, 23],
  fieldColors: {count: '0x008000', percent: '0xFFA500'},
  'annotation.categoryColors': {count: '0x008000', percent: '0xFFA500'},
  fieldDashStyles: {count: '0x008000', percent: '0xFFA500'},
}}
```

<a name="15.1.0"></a>

## 15.1.0

Users of DynamicEditor may pass a function `transformLayout={({ layout, visualization }) => layout}` as a prop which can be used to dynamically alter the editor layout at runtime.

<a name="11.0.0"></a>

## [10.2.0] to [11.0.0]

### BREAKING CHANGES

- add new marker gauge visualization, and remove splunk-charting based marker gauge. Encoding (value) is added to new marker gauge. Options are changed in new marker gauge.
  Example:

```
import React from 'react';
import MarkerGauge from '@splunk/dashboard-visualizations/MarkerGauge';

export default () => (
    <MarkerGauge
        encoding={{
            value: "primary[0]",
        }}
        options={{
            orientation: "horizontal",
            majorUnit: "10",
        }}
        dataSources={{
            primary: {
                requestParams: { offset: 0, count: 20 },
                data: {
                    fields: [{ name: 'count' }],
                    columns: [['78']],
                },
                meta: { totalCount: 20 },
            },
        }}
    />
);
```

<a name="7.0.0"></a>

## 6.0.0 to 7.0.0

### BREAKING CHANGES

- add new filler gauge visualization, and remove splunk-charting based filler gauge. Encoding (value, gaugeColor) is added to new filler gauge. Options are changed in new filler gauge.
  Example:

```
import React from 'react';
import FillerGauge from '@splunk/dashboard-visualizations/FillerGauge';

export default () => (
    <FillerGauge
        encoding={{
            value: "primary[0]",
        }}
        options={{
            orientation: "horizontal",
            majorUnit: "10",
        }}
        dataSources={{
            primary: {
                requestParams: { offset: 0, count: 20 },
                data: {
                    fields: [{ name: 'count' }],
                    columns: [['78']],
                },
                meta: { totalCount: 20 },
            },
        }}
    />
);
```

<a name="6.0.0"></a>

## 5.2.0 to 6.0.0

### BREAKING CHANGES

Removed the following options from SingleValueRadial and SingleValueIcon: 'colorBy', 'colorMode', 'trendColorInterpretation', 'rangeValues', 'rangeColors'. Some of these have been replaced by `fill` encoding.
Example:

```
encoding={{
    trend: 'primary[0]',
    fill: {
        field: 'primary[0]',
        format: {
            ranges: [0, 100, 500, 1000, 5000],
            values: ['#0000FF', '#800080', '#FFFF00', '#FFA500', '#A52A2A'],
        },
    },
}}
```
