A collection of composable React components for building interactive data visualizations
OTHER License
Bot releases are hidden (Show)
#1531 - Adds a VictoryHistogram
component. Huge thanks to @NgoKnows for this new feature!
<VictoryHistogram
binSpacing={1}
bins={[0, 20, 50, 500]}
data={[
{ value: 1 }, { value: 1 }, { value: 2 }, { value: 3 } ...
]}
x="value"
/>
Histogram bins may be defined with the bin
prop, which takes either an array of bin edges, or a single number which corresponds to an approximate number of bins. VictoryHistogram
is meant to work with continuous data, and expects a data prop as an array of objects with x values. By default, histogram bins will be laid out with no spaces between bins, but the optional binSpacing
prop may be provided to change this behavior. Additional documentation and examples here: https://formidable.com/open-source/victory/docs/victory-histogram
#1558 - Adds a backgroundComponent
for VictoryChart
that will be rendered if VictoryChart
's style
component includes background
styles. The Background
component renders a rect
for cartesian charts and a circle
for polar charts that is correctly sized and positioned to fill the entire range of the chart. Thanks @maddles and @wparsons!
Update typescript types for all Victory components. A huge thanks to @maddles @wparsons and @kale-stew for this work. This release includes the following PRs
#1557, #1556, #1554, #1552, #1551, #1550, #1547, #1546, #1543, #1538, #1536, #1535, #1534, #1533, #1532, #1530,#1529, #1528, #1527, #1526, #1525, #1524, #1522, #1521, #1520, #1519, #1515, #1514, #1512, #1510, #1508
#1481 - Add typescript types from the definitely-typed
project so that we can maintain them more easily going forward
This version uses the context API introduced in [email protected]
Changes for functional props and styles:
Related PR: #1360
Functional props like labels
and functional styles will now be called with a single argument instead of datum
and active
. The argument passed to functional props and styles will be an object containing all the props that control the rendering of the the target the prop applies to. Including things like datum
, active
, index
, data
, scale
, etc. We hope this will give users a lot more flexibility and control. In most cases, this change should be very straightforward to apply
old:
labels={(d) => `x: ${d.x}`}
new
labels={({ datum }) => `x: ${d.x}`}
Gotchas:
cornerRadius
function that depends on barWidth
, do not also make barWidth
a function of some other prop.y
and x
, and tickFormat
. The arguments for these props have not changed.Changes for VictoryCandlestick
labels
Related PR: #1295
VictoryCandlestick
now has granular support for labels corresponding to each portion of the candle. The current labels
and labelComponent
props will be joined by new props corresponding to each part of the candle.
New props
lowLabels
lowLabelComponent
highLabels
highLabelComponent
openLabels
openLabelComponent
closeLabels
closeLabelComponent
This will be a breaking change affecting the positioning of the default label
. In earlier versions, the default label was positioned above the candle, it will now be positioned next to the center of the candle.
To use older label positioning, use highLabels
/ highLabelComponent
rather than label
/ labelComponent
. If you are using tooltips with VictoryCandlestick
, you will need to register a custom event to trigger your highLabels
tooltip:
example:
<VictoryCandlestick
highLabels={({ datum }) => datum.high}
highLabelComponent={<VictoryTooltip />}
events={[{
target: "data",
eventHandlers: {
onMouseOver: () => ({ target: "highLabels", mutation: () => ({ active: true }) }),
onMouseOut: () => ({ target: "highLabels", mutation: () => ({ active: false }) })
}
}]}
/>
The style
prop for VictoryCandlestick
now also has namespaces for the new labels in addition to the current labels
namespace. When both labels
and specific label styles (e.g. highLabels
) are provided, the styles will be merged
Changes for VictoryVoronoiContainer
Related PR: #1371
Before this version VictoryVoronoiContainer
had limited functionality for mouse-following tooltips, and for constraining a tooltip to the chart area, but it was only usable for multi-point tooltips (with voronoiDimension
), and was not user configurable. This version aims to correct these limitations:
mouseFollowTooltips
: This new boolean prop on VictoryVoronoiContainer
determines whether the labels should follow the mouse position or snap into place. (Note that in charts using voronoiDimension
, the tooltip still follows the mouse in the non-voronoiDimension
, as demonstrated in the charts below (both with voronoiDimension="x"
)mouseFollowLabels={true}
mouseFollowTooltips={false}
VictoryVoronoiContainer
will no longer be constrained to the chart area by default. Instead, add the constrainToVisibleArea
prop to VictoryTooltip
to enable this behavior for both multi-point and single point tooltips:containerComponent={
<VictoryVoronoiContainer
labelComponent={<VictoryTooltip constrainToVisibleArea />}
/>
}
Changes for VictoryTooltip
and VictoryLabel
Related PR:#1371
The changes we wanted to make to support new behaviors in VictoryVoronoiContainer
required some changes to VictoryTooltip
and VictoryLabel
New props for VictoryTooltip
:
constrainToVisibleArea
is a boolean prop that, when true, will alter the position of the tooltip so that it exactly fits within the svg Victory renders. The tooltip's center will be moved, but the pointer will remain pointing at the associated x
, y
value of the tooltip. When this prop is set to true, pointerLength
may not be respected
center
is a prop that may be given as an object with values or functions for "x" and "y". When this prop is set, it will position the center of the tooltip (centered around the main body of the tooltip, minus the pointer). When this prop is not set, it will be calculated from other props such as x
, y
, pointerLength
, etc. This prop was added to enable mouse-following tooltips in VictoryVoronoiContainer
.
centerOffset
is a prop that may be given as an object with values or functions for "x" and "y". When this prop is set, the center of the tooltip will be offset by some amount from the x, y value it points to, resulting in a slanted pointer. When this prop is set, pointerLength
will not be respected (because the pointer will be slanted)
flyoutHeight
(formerly height
): This optional prop determines the height of the tooltip flyout (minus pointer). The name of this prop was changed so that it would not conflict with the height
prop now passed to VictoryTooltip
by its parents
flyoutWidth
(formerly width
): This optional prop determines the width of the tooltip flyout (minus pointer). The name of this prop was changed so that it would not conflict with the width
prop now passed to VictoryTooltip
by its parents
width
: the overall width of the parent svg. This prop will be passed down from any victory component that uses VictoryTooltip
as a label
height
: the overall height of the parent svg. This prop will be passed down from any victory component that uses VictoryTooltip
as a label
Changes Affecting VictoryLabel
and VictoryTooltip
x
and y
values passed to labels by their parent components have all been adjusted so that their values match the position of the data point they correspond to. All padding is now accounted for in the dx
and dy
props instead of being added directly to x
and y
.x
and y
props they receive, or providing their own dx
/ dy
props. These breaking changes may take a bit of manual adjustment to correct, but we hope this change will make label positioning easier to reason about in the long run.Other Changes
We have been concurrently working on improving performance and the stability of events in victory-native
. The following changes have been added to support these efforts:
Related PR: #1373
prependDefaultAxes
boolean prop has been added to VictoryChart
. This prop will be set true by default in victory-native
to reduce the possibility of axis elements to interfere with events.Related PR: #1365
Bar
, Path
etc) with for function primitives to match performance-improving changes in victory-native
. (This is a breaking change for anyone extending from victory
components)Published by boygirl over 5 years ago
2019-02-27
Horizontal Chart Improvements!
The goal of this change is to make it possible to turn any existing chart into a horizontal chart by adding the horizontal
prop to the chart without needing to alter any other props.
x
value always refers to the independent dimension, and the y
value always refers to the dependent dimension.VictoryAxis
components is no longer tied to whether or not they are the dependentAxis
Breaking Changes
Most Horizontal Charts
The change in how props with x and y values are treated (i.e. scale
, domain
, etc) will be a breaking change for most horizontal charts. In most cases, reversing the x
and y
values of props you are providing to your horizontal chart will be sufficient to correct the change. For example:
<VictoryChart horizontal scale={{ x: "log" }} domain={{ y: [4, 9] }}>
<VictoryBar
data={[
{ x: 5, y: 0.1 },
{ x: 6, y: 1 },
{ x: 7, y: 10 },
{ x: 8, y: 100 }
]}
/>
</VictoryChart>
Should be changed to:
<VictoryChart horizontal scale={{ y: "log" }} domain={{ x: [4, 9] }}>
<VictoryBar
data={[
{ x: 5, y: 0.1 },
{ x: 6, y: 1 },
{ x: 7, y: 10 },
{ x: 8, y: 100 }
]}
/>
</VictoryChart>
Props affected by this change are: scale
, domain
, maxDomain
, minDomain
, domainPadding
, and categories
Horizontal Charts with Event Containers
Dimension props such as brushDimension
have changed so that they always refer to the dimension of the target variable (x for the independent variable, and y for the dependent variable). For example, a VictoryBrushContainer
component with brushDimension="x"
will move and expand only in the independent dimension regardless of whether the chart is horizontal.
Props affected by this change are: brushDimension
, cursorDimension
, selectionDimension
, voronoiDimension
, and zoomDimension
Horizontal Charts with Custom dataComponents
The position values (i.e. x
, y
, x0
, y0
) supplied to custom dataComponents
from components like VictoryChart
will be scaled for the layout of the horizontal chart. Users who rely on these values may need to flip them or adjust them depending on their use case
Horizontal VictoryBoxPlot
Previously VictoryBoxPlot
required data to be flipped (x values flipped with y values) in order to plot horizontal charts. This is no longer required, and providing data in this format will no longer work correctly. To correct for this change, it should be sufficient to flip the data used in horizontal charts
Published by boygirl over 5 years ago
(2019-01-27)
Axis improvements
axisValue
prop for both cartesian and polar charts. This prop allows users to position an axis relative to a value on the opposite axis. Values may be given as numbers, dates, or strings. This prop only works for axis components when they are nested within VictoryChart
. Standalone axes can still be positioned using offsetX
and offsetY` props.Removes all deprecated lifecycle methods
componentWillReceiveProps
lifecycle methods and adds shouldComponentUpdate
logic for higher level components. Previously only the lowest level components performed sCU
checks.componentWillMount
with componentDidMount
bug fixes
Published by boygirl over 5 years ago
(2019-01-08)
1222 Bugfix: Avoid rendering null values on discrete data
1218 Bugfix: Ensure that calculated domains respect custom baselines for VictoryBar and VictoryArea
1202 Bugfix: Correct missing bar values
1208 Performance: Improve performance in addEventKeys
1211 Performance: Optimize stringMap calculations
1212 Performance: Optimize for preformatted data:
When data objects already contain _x
, _y
(and _y0
where appropriate) and have data accessor props like x="_x"
, data will no longer be formatted by Victory, but will be used as is.
Example:
<VictoryArea
data={[ { _x: 0, _y0: 1, _y: 2 } ...]}
x="_x"
y="_y"
y0="_y0"
/>
1209 Feature: Adds an animationWhitelist
property to the animate
prop. This property should be given as an array of strings. When this prop is given, only the prop names matching the array will be animated, and all other props will be instantaneously updates.
Example:
<VictoryBar
animate={{
animationWhitelist: ["data"]
}}
data={this.state.data}
style={{
data: this.state.style
}}
/>
When this property is not set, the static animationWhitelist
of any given component will be used.
Published by boygirl over 5 years ago
(2018-11-10)
radius
, innerRadius
, cornerRadius
, padAngle
, sliceStartAngle
and sliceEndAngle
for each individual slice of a pie:Details:
The Slice
primitive used by VictoryPie
now takes radius
, cornerRadius
, innerRadius
, padAngle
, sliceStartAngle
and sliceEndAngle
props. Each of these props may be given as number or a function of datum
and active
. padAngle
, radius
, cornerRadius
and innerRadius
will be passed down from props on VictoryBar
, but sliceStartAngle
and sliceEndAngle
must be defined directly on the Slice
instance, These values should be given in degrees. To make these values easier to use as functional props, startAngle
, endAngle
, and padAngle
(in degrees) are added to each datum
passed into Slice
. (If your data already has these properties they will not be overridden)
Breaking Changes
The Slice
primitive will still take a pathFunction
prop, but this prop will no longer be provided by VictoryPie
. This will not be a breaking change for most users. This will only affect users who were wrapping the Slice
component and making use of the pathFunction
prop provided by VictoryPie
Users who were providing their own pathFunction
prop to Slice
should not be affected.
Published by boygirl over 5 years ago
(2018-10-26)
barWidth
functions were not being correctly evaluatedcornerRadius
improvements for VictoryBar
cornerRadius
values larger than the height of the bar have been correctedcornerRadius
now supports topLeft
, topRight
, bottomLeft
and bottomRight
values in addition to existing values. This is not a breaking change. These values may be used alongside existing values for top
and bottom
, but more specific values will override less specific values.