Show sample tooltips on sample graph hover #5298
Conversation
…graph Previously we were always returning the closest sample to the mouse hover/click location. Which was okay when we were clicking to select the boxes before. But now we are also showing tooltips on hover which can be misleading if they were shown when we are not hovering over them. So to make this experience less confusing, this commit changes the behavior to only select or hover a specific sample when the mouse is actually on top of the sample box that we draw.
Previously we were using the exact same algorithm as the activity graph. Activity graph tests get the value in between this and the next same time. But for these tests, we actually want the exact sample time.
canova
force-pushed
the
tooltip-sample-graph
branch
from
16bcdf4 to
54e08da
Compare
|
Looks nice, thanks! Some feedback (can be handled in follow-ups) :
|
There was a problem hiding this comment.
It's great to see this tooltip now, we can always improve the look and fix the small issues later.
I noticed that sometimes hit testing is a bit off: my mouse cursor is clearly on the rectangle, yet the tooltip doesn't appear. It seems to happens at some page zoom levels only. If the fix is easy you can do it now, but if you don't find the source now, it's fine to look at it later.
Also I think the hit target is a bit small and we might want to increase it to some more than just the rectangle. But that could be for later too.
Thanks!
| autoMockCanvasContext(); | ||
| autoMockElementSize({ width: GRAPH_WIDTH, height: GRAPH_HEIGHT }); | ||
| autoMockIntersectionObserver(); | ||
| beforeEach(addRootOverlayElement); | ||
| afterEach(removeRootOverlayElement); |
There was a problem hiding this comment.
I kind of feel like this should move to our setup eventually :-)
(not now)
| ) => void, | ||
| +trackName: string, | ||
| +timelineType: TimelineType, | ||
| implementationFilter: ImplementationFilter, |
| +timelineType: TimelineType, | ||
| implementationFilter: ImplementationFilter, |
There was a problem hiding this comment.
There is a little performance inefficiency here, that's a reason why in other components, the canvas part is in a separate component compared to the tooltip (see ActivityGraph for example).
Indeed the canvas is redrawn at each render of this component (because it's called in componentDidUpdate). So with these new props, the canvas would be redrawn when timelineType or implementationFilter is changed despite that this doesn't influence the drawing.
The fix is to create a separate component for the canvas. It could be in the same file, I don't mind.
|
|
||
| const rect = canvas.getBoundingClientRect(); | ||
| this.setState({ | ||
| hoveredPixelState: this._getSampleAtMouseEvent(event), |
There was a problem hiding this comment.
_getSampleAtMouseEvent only needs pageX (that we have in the state), so we could call it at render time instead of at event time. Very likely this would result in some performance improvement, because React renders less often than move events are triggered.
(although I believe synthetic move events might be throttled already, but likely not as much as rendering)
| const r = canvas.getBoundingClientRect(); | ||
|
|
||
| const x = event.pageX - r.left; | ||
| const time = rangeStart + (x / r.width) * (rangeEnd - rangeStart); | ||
|
|
||
| const range = [rangeStart, rangeEnd]; | ||
| const rangeLength = range[1] - range[0]; |
There was a problem hiding this comment.
nit: rangeEnd - rangeStart
| 0.8, | ||
| trueIntervalPixelWidth * multiplier | ||
| ); | ||
| const drawnSampleWidth = Math.min(drawnIntervalWidth, 10) / 2; |
There was a problem hiding this comment.
it could be better to extract this computation to a separate function, so that we're sure we always have the same one in drawCanvas and here.
| const drawnSampleWidth = Math.min(drawnIntervalWidth, 10) / 2; | ||
|
|
||
| const maxTimeDistance = | ||
| (drawnSampleWidth / 2 / r.width) * (rangeEnd - rangeStart); |
| const { rangeStart, rangeEnd, thread, interval } = this.props; | ||
| const r = canvas.getBoundingClientRect(); | ||
|
|
||
| const x = event.pageX - r.left; |
There was a problem hiding this comment.
optional: event.offsetX is equal to this value. But I don't remember if it's available on the React's event or if we need to access it with nativeEvent.offsetX. (I think this was the case before but it may be available now)
(optional because we need to call getBoundingClientRect to get the width anyway, so it's only a matter of code style)
Fixes #3363.
This was requested by multiple people because sometimes it's not clear to users what the squares in the sample graph are. For example latest feedback we got was in #5278. They also said that a tooltip would've helped.
Deploy preview / Production