@splunk/visualizations 26.0.0 → 26.1.1

package/MIGRATION.md

@@ -0,0 +1,1082 @@
+# Migration
+
+<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'],
+        },
+    },
+}}
+```