Documentation / @finchart/core / index / CoordinateAccessor
Interface: CoordinateAccessor<T>
Defined in: packages/core/src/data/types.ts:79
Pulls display x/y coordinates out of a point.
Type Parameters
T
T extends BaseDataPoint = BaseDataPoint
Properties
gapless?
readonlyoptionalgapless?:boolean
Defined in: packages/core/src/data/types.ts:175
Declares that this accessor can never produce a gap. If omitted, assume it can.
getY's return type already knows this fact (number vs. number | null), but the runtime can't read the type, so this is where that fact gets written down again as a value.
What this saves: checking gap presence by calling getY over the whole window every frame is hundreds of thousands of calls on a large window. For a series whose answer is always "no" (bars, etc.), this declaration removes that scan entirely. The viewport cache can't help here — gap presence is a property of the array, not the window.
Declaring this falsely swallows gaps — never declare it if getY can return null or undefined.
uniqueX?
readonlyoptionaluniqueX?:boolean
Defined in: packages/core/src/data/types.ts:192
Declares that one x holds one point — a bar per moment. If omitted, a repeated x is legal (two points at one moment: line data's contract).
Like gapless, a static fact about the accessor written down as a value (gapFree on the manager is the array's runtime state — a different thing). Unlike gapless, the risk runs the other way: declaring gapless falsely swallows a gap quietly, while declaring uniqueX makes every door loud — a repeated x at setData, a seam, or the tick's previous bar is a DataError (duplicate-x), and data that was legal without the declaration is rejected with it. Declare it only where a repeat is a defect, not a second point: the reconnect gap-fill that hands back the boundary candle twice is the case this exists for.
Methods
assertFinite()?
optionalassertFinite(point,index,label?):void
Defined in: packages/core/src/data/types.ts:133
Are all of this point's value fields finite? If not, throw DataError. label names the door the point came through ("data" for a whole array, "updateLast(point)" for a tick) — put it in front of the message, so a consumer reading a socket callback's error knows which call it was. Omitted, say "data".
If omitted, the data gate only checks getY — for a line or a derived series where there's one value, that's enough. For OHLC, where there are four, you must implement this: getY only reads close, so open, high, and low pass through no gate at all.
One bar with close: null drew a 7140px red bar in a 600px pane, and close: "102" produced not a broken screen but a wrong one — a perfectly normal-looking bar that reads as a doji. Not failing to draw, but confidently drawing the wrong price — the worst failure a financial chart can produce.
Where the value comes from: exchange REST APIs give prices as strings. Unwrap open/high/low with + and let one close slip through and that's the row. close: null on a closed or unfilled bar is just an ordinary day on the feed, and parseFloat("") is NaN.
The cost was measured: on 100k bars, a loop that only touches x takes 0.10ms; checking all four OHLC fields in the same loop still takes 0.10ms — same loop, no extra pass. But laying the fields out by hand instead of a loop over them (iterator allocation plus a dynamic lookup per point) is more than twice as slow — ohlc-fields.test.ts guards against a dropped field.
Parameters
point
T
index
number
label?
string
Returns
void
getPositiveFloor()?
optionalgetPositiveFloor(point):number|null
Defined in: packages/core/src/data/types.ts:156
The smallest positive value this one point holds on the axis — what a log axis stands on when the point dips to zero or below. If omitted, the point's positive floor is its range's min (then getY) when that is positive, and nothing otherwise — right for a candle, whose low is its lowest value, and wrong for a point that holds more values than its range names, such as a column of boxes whose lowest box is below zero and whose next is not: without this door the log axis is fitted from a constant instead of that box.
Parameters
point
T
Returns
number | null
getX()
getX(
point):number
Defined in: packages/core/src/data/types.ts:86
Where to place it. Can't be absent.
A point with no x isn't whitespace — it's a point that must be dropped. If you don't know where to put it, you can't even draw a gap for it.
Parameters
point
T
Returns
number
getY()
getY(
point):number|null|undefined
Defined in: packages/core/src/data/types.ts:101
What to draw. null means there's no value (whitespace).
Where there's no value the line breaks, the value range (valueExtent) doesn't count that point, and decimation doesn't swallow that spot.
Can also return undefined — meaning "couldn't read it." For the manager to point out a mismatched field name like {x, value}, that value has to surface here.
Consumers already receive all of this uniformly through isGap (line, area, histogram, baseline).
Parameters
point
T
Returns
number | null | undefined
getYRange()?
optionalgetYRange(point):Range|null
Defined in: packages/core/src/data/types.ts:144
This one point's data value span — low to high for a candle. If omitted, the point's value is just getY (line, derived).
This is a different truth than Series.valueExtent — that one is "the drawing's value span," so a histogram includes zero, while this is the span the data actually has. Using the drawing's criterion here turns snapping into a bug that sticks to a histogram's zero.
Parameters
point
T
Returns
Range | null