fix(Tooltip): identity-check mouseout target and track node position on view changes#209
Open
w8r wants to merge 7 commits into
Open
fix(Tooltip): identity-check mouseout target and track node position on view changes#209w8r wants to merge 7 commits into
w8r wants to merge 7 commits into
Conversation
…on view changes Two bugs fixed in the hover-event Tooltip: 1. **Premature close on foreign mouseout** The `mouseout` listener was firing for *any* node/edge mouseout, not just the one that triggered the tooltip. Rapidly moving between nodes or across an edge would cause a foreign `mouseout` to immediately close the tooltip. Fix: mirror `target` state into a `targetRef` and guard the hide call with an identity check (`evt.target === targetRef.current`). 2. **Stale position after node drag or zoom** The tooltip position was computed once on hover and never updated when the node was dragged or the view zoom changed (zoom affects the radius-based offset). Fix: subscribe to `nodesDragProgress` and `idle` events; on each fire recompute the node's current graph position and the zoom-adjusted offset, then call `layer.setPosition` and trigger the existing overflow re-check via `setPoint`. A `pointRef` is added alongside `targetRef` so both callbacks can read current values from stable closures without being re-registered on every hover change.
…a popup and tooltips on node / edge hover
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Two bugs in the hover-triggered
<Tooltip>component:1. Premature close on foreign
mouseoutThe
mouseoutlistener was firing for any node/edgemouseout, not just the element that triggered themouseover. Rapidly moving between two adjacent nodes would cause a foreignmouseoutto immediately close the tooltip.Root cause: the handler only checked
evt.target?.isNode(correct type) but never verifiedevt.target === storedTarget(correct identity).2. Stale tooltip position after node drag or zoom
The tooltip position was computed once at hover time and never updated when:
Fix
Identity check: Mirror
targetstate into atargetRefso the stable event-handler closure can always read the current value. GatehideTooltip()onevt.target === targetRef.current.Position tracking: Declare a hoisted
onViewUpdatecallback (registered onnodesDragProgressandidle) that reads the node's current graph position vianode.getPosition(), recomputes the zoom-adjusted offset, callslayer.setPosition(), and triggers the existing overflow re-check by callingsetPoint().A
pointRefis added alongsidetargetRefso both callbacks can read current values from stable closures without being re-registered on every hover change.Checklist
npm run typecheck)