fix #5459: resolve duplicate hover entries in segmented line charts#5558
fix #5459: resolve duplicate hover entries in segmented line charts#5558MarioSilvestre2901 wants to merge 1 commit intoplotly:mainfrom
Conversation
…arts When adjacent scatter traces share an endpoint, 'x unified' hover shows two entries at the same x value. Fix by splitting each chain trace into a visual-only drawing (hoverinfo='skip') and one single-point companion per data point. Each trace owns its points up to but not including the shared last endpoint, which is instead covered by the following trace as its x[0], ensuring the companion carries the correct customdata
Pawansingh3889
left a comment
Pawansingh3889
left a comment
There was a problem hiding this comment.
Thorough fix — the approach of splitting chained traces into visual-only drawings (hoverinfo="skip") plus single-point companion traces is clever and avoids modifying the rendering pipeline.
A few observations:
-
Performance:
_fix_segmented_hoverruns insideto_dict(), which gets called frequently (renders, exports, serialization). For figures with many traces, the pairwise endpoint comparison in_traces_share_endpointcould add up. Have you benchmarked with a figure containing 50+ scatter traces? -
Test coverage: The three tests cover the core cases well — especially the customdata edge case at shared endpoints belonging to the next trace. Worth adding a test for traces with
None/empty x arrays to make sure the guard clause handles them. -
Naming:
_build_hover_companionclearly describes intent. The method names are self-documenting which is great for a codebase this large.
Clean implementation overall. The 146 additions are well justified given the test coverage included.
2 participants
Link to issue
#5459
Closes #5459
Description of change
When adjacent scatter traces share an endpoint, 'x unified' hover shows two entries at the same x value. Fix by splitting each chain trace into a visual-only drawing (hoverinfo='skip') and one single-point companion per data point.
Each trace owns its points up to but not including the shared last endpoint, which is instead covered by the following trace as its x[0], ensuring the companion carries the correct customdata
Demo
https://www.youtube.com/watch?v=ZmALODtTiDw
Testing strategy
Three unit tests were added: one guards against regression for non-sharing traces, one verifies the full chain expansion (2 drawing + 3 companion traces), and one targets the edge case where the shared-endpoint companion must carry the next trace's customdata rather than the previous trace's last point.
Additional information (optional)
When I first started working on this issue, I thought the problem was related to the last point of the line. However, I later realized that it was actually related to the last point of each segment.
Using the file described in the issue, the last point’s performance will always be 0% because no performance value is being passed to Plotly for that point.
I fixed the duplicate and incorrect values for the last point of each segment, but with the file provided in the issue, the last point of the line will still always show 0%.
Guidelines