v8.x -> v9.x
When upgrading, please reference each of the below LCJS entries in your application (for example, using Search functionality in your code base).
For each code block found this way, refer to the corresponding migration guide.
DataSetXY
Renamed to DataSet as it is no longer strictly XY feature. It can also be used with 3D series.
Similarly, other derived exports are renamed (for example, DataSetXYOptions -> DataSetOptions)
readback
The type definition of DataSet.readback has changed slightly. If you were using readback on a SERIES object, the type definition is unchanged!
After v9.0 dataset readback operations can also return BigInt64Array entries.
This can show as type errors after upgrade because bigint arrays require different handling logic than other typed arrays, such as Float64Array.
If you know your application doesn't supply BigInt64Arrays to dataset API, then you can safely type cast back to TypedArray.
PointSeries3D, PointCloudSeries3D, LineSeries3D, PointLineSeries3D
These series have been updated to use the new data API syntax that has already been used in XY series for few years now.
The APIs between XY and 3D are now symmetric, and you can even share the same DataSet object between XY and 3D series.
- Removed
addmethod. UseappendJSON,appendSamplesorappendSampleinstead - Removed
getPointAmount. UsegetSampleCountinstead - Removed
individualPointColorEnabledoption. New syntax is to define color property as part of schema and map it tocolor(similarly as previously in XY series) - Removed
individualPointSizeEnabledoption. New syntax is to define size property as part of schema and map it tosize(similarly as previously in XY series) - Removed
individualPointSizeAxisEnabledoption. New syntax is to define size property as part of schema and map it tosizeAxis - Removed
individualLookupValuesEnabledoption. New syntax is to define size property as part of schema and map it tolookupValue(similarly as previously in XY series)
AreaRangeSeries
This series has also been updated to use the new data API syntax from other XY series. However, as Area range series requires slightly different input data than other XY series, the API's aren't 100% same.
Data input
Previously data was supplied with add method. Below you can find respective data input with new API:
// Before
areaRangeSeries.add([
{ position: 0, low: 100, high: 200 },
{ position: 10, low: 50, high: 220 },
{ position: 20, low: 75, high: 250 },
])
// After
const series = chart.addAreaRangeSeries({
schema: {
position: { pattern: 'progressive' },
low: { pattern: null },
high: { pattern: null }
}
})
series.setDataMapping({ position: 'position', range1: 'low', range2: 'high' })
series.appendJSON([
{ position: 0, low: 100, high: 200 },
{ position: 10, low: 50, high: 220 },
{ position: 20, low: 75, high: 250 },
])
Alternatively, columnar input data can be supplied using appendSamples.
These methods behave exactly same as in other XY series, the only difference being how data mapping is defined.
Styling
Previous style APIs like setLowFillStyle, setHighFillStyle, setHighStrokeStyle etc. have been replaced with slightly more lean methods: setStrokeStyle, setAreaFillStyle, setPointFillStyle
By default, these affect both the below and above sides of Area range series at once. If necessary, only one side can be configured like this:
series.setPointFillStyle(new SolidFill({ color: ColorRGBA(255, 0,0) }), { range1: true, range2: false })
New functionality
While the main purpose of this rework is to make the Area range series API symmetric with other XY series, this also brings several new features and improvements to the old feature:
setMaxSampleCount,readBack,edit...etc. APIs- Ability to share datasets between Area range series and other XY series by using the same DataSet object and varying on data mapping
- Vertical and regressive Area range series
- Massive performance improvements
- Previously Area range series performed thousands of times weaker than other XY series (in terms of data input speed, max data capacity, etc.). Now it has been upgraded to perform on same level as other XY series.
Default axis type changed from linear to linear-highPrecision
In majority of apps, this should not require any attention nor should it result in any changes visually or behaviorally.
The only exception is if your application uses addAxisX or addAxisY method to create a logarithmic axis!
// Before
const chart = lc.ChartXY()
const axisLog = chart.addAxisY({ type: 'logarithmic' })
// After
const chart = lc.ChartXY({ defaultAxisX: { type: 'linear' } })
const axisLog = chart.addAxisY({ type: 'logarithmic' })
This change is done mainly with new users in mind, so they don't need to bother enabling high precision axis when dealing with high precision timestamps.
In use cases with non-default logarithmic axis, explicit downgrade to linear axis is required because high precision and logarithmic axes can't be combined.
If this situation is encountered in runtime, the library will print migration instructions to console also.