-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Issue 4991 #7084
Issue 4991 #7084
Conversation
4bb92bf
to
bd5243e
Compare
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'm not sure what happens if we declare only some of the types. That seems like it'd make it hard to use with DefinitelyTyped. I wonder if we want to hold off on that unless we can do them all. Maybe work on it in a separate branch if we want to go that way
We would need to add the types to release, to be usable. (Also I don't think the DefinitelyTyped spec works at all with v3, so if we have a place for them here, I bet we get PR's for them) |
removed the not needed changes. |
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.
No objections to this. Agree on the doc comments that @benmccann had
@kurkle this one will need to be rebased |
const hoverOptions = options.hover; | ||
// If the event is replayed from `update`, we should evaluate with the final positions. |
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.
Can you explain more why the position from update
might not be the final position?
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.
Element's properties are its current state ("view" in 2.9) and the animations contain the target ("model" in 2.9). So when animations are enabled, after update and before first animation frame, elements x/y are exactly the same than before update. Only the animations were updated. The Animator then updates the elements in each frame.
Sorry for my delay on reviewing. Would you mind sharing an interactive example for this one? I want to play around and test a few things |
In the codepen, if I leave my mouse over a segment of the pie and then don't touch it, the tooltip just stays in the same place and doesn't update the value it's displaying despite the data changing |
Good catch! Fixed! |
I found a couple more issues:
|
I saw you pushed a new commit. Now sure if you updated the codepen, but it's working the same for me |
I did update the pen. The code is in another pen though, so there could be caching. |
Here's the same pen using master: https://codepen.io/kurkle/pen/MWwjvaw |
It seems to be working pretty well now though I did get one quirk. I'm not quite sure how to make an animated gif, but here's a screenshot of an instance where the tooltip was placed a bit oddly. I think that it may happen when the mouse is in Data 1, that segment gets a data value of 0 (now the mouse is in Data 2 as a result), and then the next update when it reappears in Data 1 it does so in an unexpected location. |
Additionally fixed the alignment, size and caret position of tooltip. Pen updated. |
If I just leave my mouse stationary over one of the segments, the tooltip no longer moves as it should when the segment sizes change (I was looking at https://codepen.io/kurkle/pen/MWwjvaw) |
Look at the other pen, that one is how master works. The one using this PR: https://codepen.io/kurkle/pen/yLNJwJZ |
Sorry about that and thanks for the correction It looks pretty good. I tried to slow it down quite a bit to do some final checks. I was following
|
I filed a new issue about the animation documentation. |
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.
The behavior in the pen all looks good to me. Just had a minor suggestion about adding some more explanation in the code. Thanks for the patience on this one
const hoverOptions = options.hover; | ||
// If the event is replayed from `update`, we should evaluate with the final positions. |
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.
Could you expand this comment a little? There's a lot going on here, so I just want to make sure I understand correctly.
I think the following is perhaps true:
- It's referring the final position after this
update
- The event will have mouse coordinates from the last event. This should basically be where the mouse is currently
Why do we handle the event at the final position? Once the animation starts it will move it back to the initial position and then animate it back towards the final position?
On top of #7080
This is quite big, I'll split if needed.
Closes: #4991
Master
pen for master
PR
pen for pr