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
Graph NG: exemplars support WIP #28071
Conversation
// An abstraction over a component rendered within a chart canvas. | ||
// Marker is rendered with DOM coords of the chart bounding box. |
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.
// An abstraction over a component rendered within a chart canvas. | |
// Marker is rendered with DOM coords of the chart bounding box. | |
/** | |
* An abstraction over a component rendered within a chart canvas. | |
* Marker is rendered with DOM coords of the chart bounding box. | |
*/ |
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.
I really like this! Left some minor nits for consideration.
canvasRef: any; | ||
data: DataFrame; | ||
} | ||
|
||
export const PlotContext = React.createContext<PlotContextType | null>(null); | ||
export const PlotContext = React.createContext<PlotContextType>({} as PlotContextType); |
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.
nit: I think using null is clearer here, but no biggie
` | ||
)} | ||
> | ||
<div ref={markerRef} onMouseEnter={onMouseEnter} onMouseLeave={onMouseLeave} className={cx(styles.markerWrapper)}> |
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.
nit: don't think you need cx
in this case
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.
Awesome job!
Think there are some follow-up issues we need to look at.
- Not sure if we should continue using AnnotationEvent, think @ryantxu have plans to deprecate that and use DataFrame directly instead. For example, AnnotationEvent does not have data links that we need for the exemplars. but the field has data links.
- Observable & useEffects only for simple data model transforms feels inefficient (both for this here and in the main GraphPanel for getting aligned data). Need sync util functions for merge & join transforms.
Yup, aware of that. Using the AnnotationEvent here is just to keep the ball rolling :) |
@torkelo @ryantxu removed the usage of the AnnotationEvent in favor of DataFrame (and DataFrameView for fields inspection) in Annotations & Exemplars plugins. FYI @zoltanbedi |
* Use annotations data observable * WIP exemplars * Refactor usePlotContext to use getters instead of properties * Use DataFrame in EventsCanvas instead of custom type * Minor tweaks
This PR brings some refactorings in order to support exemplars in the same way as annotations.
Main highlights of the changes proposed:
T extends AnnotationEvent
that we will probably need to adjust to something shared between annotations and exemplars. Uses simple primitiveXYCavas
under the hood for the Markers to be rendered in correct positionsplotCtx.u && plotCtx.u.series && plotCtx.canvas
) the context now exposesisPlotReady
property tat indicates it's safe to use all the getters.TODO:
valueToPos
API. For this to work we need to identify which scale are the exemplars using. @zoltanbedi currently the scales in the graph are created using Field's unit configuration. If there is no unit configured then the default scale is called '_fixed'. I assume for the exemplars we won't have a unit? What's the thinking about this?