-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(heatmap): snap time bucket to calendar/fixed intervals #1462
Changes from 5 commits
e99af4c
4f6e7c5
5c16f84
7c89a57
eb00c5d
bc0fffd
100bf5b
296d46e
500f58f
7a0d7db
4057868
f623e80
59882e3
0eb451a
ad7c7d0
985e3fc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -709,6 +709,29 @@ export const entryKey: ([key]: ArrayEntry) => string; | |
// @public (undocumented) | ||
export const entryValue: ([, value]: ArrayEntry) => ArrayNode; | ||
|
||
// @public (undocumented) | ||
export type ESCalendarInterval = { | ||
type: 'calendar'; | ||
unit: ESCalendarIntervalUnit; | ||
value: number; | ||
}; | ||
|
||
// @public (undocumented) | ||
export type ESCalendarIntervalUnit = 'minute' | 'm' | 'hour' | 'h' | 'day' | 'd' | 'week' | 'w' | 'month' | 'M' | 'quarter' | 'q' | 'year' | 'y'; | ||
|
||
// @public (undocumented) | ||
export interface ESFixedInterval { | ||
// (undocumented) | ||
type: 'fixed'; | ||
// (undocumented) | ||
unit: ESFixedIntervalUnit; | ||
// (undocumented) | ||
value: number; | ||
} | ||
|
||
// @public (undocumented) | ||
export type ESFixedIntervalUnit = 'ms' | 's' | 'm' | 'h' | 'd'; | ||
|
||
// @alpha | ||
export interface ExternalPointerEventsSettings { | ||
tooltip: TooltipPortalSettings<'chart'> & { | ||
|
@@ -1036,6 +1059,12 @@ export interface HeatmapConfig { | |
// @public (undocumented) | ||
export type HeatmapElementEvent = [Cell, SeriesIdentifier]; | ||
|
||
// @alpha (undocumented) | ||
export interface HeatmapNonTimeScale { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor: A positively stated scale name would work better, if possible. The word "scalar" implies unitlessness but it doesn't look nice next to "Scale", so, maybe, UnitlessScale? The word "Heatmap" in the scale name represents tight coupling, because it casts the Scale as a property of (subsidiary to) the chart type Heatmap, while they're at least equal, orthogonal things or even, Heatmap is subsidiary to the Scale. Of course I see how you want to rule out logarithmic etc. scales. Maybe There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. or I can completely remove that named type and use something like: xScale:
| HeatmapTimeScale
| {
type: typeof ScaleType.Ordinal | typeof ScaleType.Linear;
}; wdyt? with your consideration should also There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Part 1: I'm fine with that too, though in terms of syntax, it combines two types of unioning, where it could be just one, eg. Part 2: Neither name is something I really prefer, as both of them tightly bind a scale type to a chart type maybe needlessly, though the first option rolls off the tongue more easily to me. But the best would be, if possible, to not have a chart type name in the name of a scale type. So, something like |
||
// (undocumented) | ||
type: typeof ScaleType.Ordinal | typeof ScaleType.Linear; | ||
} | ||
|
||
// @alpha (undocumented) | ||
export interface HeatmapSpec extends Spec { | ||
// (undocumented) | ||
|
@@ -1062,7 +1091,7 @@ export interface HeatmapSpec extends Spec { | |
// (undocumented) | ||
xAccessor: Accessor | AccessorFn; | ||
// (undocumented) | ||
xScaleType: SeriesScales['xScaleType']; | ||
xScale: HeatmapTimeScale | HeatmapNonTimeScale; | ||
// (undocumented) | ||
xSortPredicate: Predicate; | ||
// (undocumented) | ||
|
@@ -1071,6 +1100,16 @@ export interface HeatmapSpec extends Spec { | |
ySortPredicate: Predicate; | ||
} | ||
|
||
// @alpha (undocumented) | ||
export interface HeatmapTimeScale { | ||
// (undocumented) | ||
interval: ESCalendarInterval | ESFixedInterval; | ||
// (undocumented) | ||
timeZone: string; | ||
// (undocumented) | ||
type: typeof ScaleType.Time; | ||
} | ||
|
||
// @public | ||
export const HIERARCHY_ROOT_KEY: Key; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily in this PR, we could eventually depend on types in
elasticsearch.js
as an authoritative sourceThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, as we have an
elasticsearch.ts
, I meant, at some point directly devDepending on https://github.com/elastic/elasticsearch-js for these types. This way, if elasticsearch adds a new unit, and we bump the dependency, we'll get automatic static errors saying that we don't cover the new unit option(s)