-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Navigator: add support for exit animation #64777
Conversation
21967f4
to
97bc8cf
Compare
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
It appears that the site editor sidebar doesn't use
|
packages/components/src/navigator/navigator-screen/component.tsx
Outdated
Show resolved
Hide resolved
304fe6a
to
0ae892a
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.
Animating presence will likely be a recurring need. How can we abstract this into something encapsulated and reusable, so we don't have to add in a bunch of ad hoc animation coordinating logic into a component every time we need an entry/exit animation?
Not immediately sure if we should use a library like react-transition-group
(maybe 1.7kB gzipped if we only needed the Transition
component), or if we want to maintain our own for an even smaller size. Thoughts?
That's true, although in many cases, animating presence can be done with some recent CSS features. But those can't be used with
I'm conflicted — on one end, I don't like to reinvent the wheel if the problem has been solved well by third-parties. On the other, we're trying to move away from If we used Also, this specific type of animation will be much easier when view transitions become more advanced and better supported in the next few years.
I wonder if doing so would represent a form of early optimization. Maybe we can keep |
0ae892a
to
9df5673
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 wonder if doing so would represent a form of early optimization. Maybe we can keep
Navigator
as-is, and re-discuss this topic if/when we have more real use cases for animating presence, so that we can better understand what type solution we'd need to implement?
I'm not familiar enough to make a confident judgement in either direction, but I trust you on your assessment after working on it.
I guess what immediately makes me a bit uncomfortable though is how the animation logic is interspersed in the component code. Do you think it would be worth the effort to extract most or all of the animation logic into a single hook? No regard for reusability at the moment, but just to isolate all the animation concerns into a single place. I'm already a bit afraid of touching this code, and I think separating the concerns would help a lot to ease that sense of complexity.
packages/components/src/navigator/navigator-screen/component.tsx
Outdated
Show resolved
Hide resolved
Rebased to include all recent |
7f2a8e4
to
68d898a
Compare
This is a great suggestion, I definitely agree. I pushed a couple of commits and things are looking much more clear :) |
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 still need to test and review this thoroughly, but I'm submitting some early, naive feedback.
- more clear animation status names - apply CSS animation only while effectively animating - fix bug in the animationEnd callback which was matching animation end events too loosely, thus causing glitches
… height Remove unnecessary import
This reverts commit 946f9c953232b788f58050d2a94d9d131527a180.
9370aa5
to
283dc1e
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 don't have any further feedback, everything has been addressed. The glitch with Typography panel is solved. I think this is ready to 🚢
This PR seems to have caused problems with the shadow preset panel and font size preset panel. Looking at the browser error log, it might be a problem with the implementation of the shadow/font size preset, but could you take a look at the following issue? |
Thank you for flagging — left a reply in the issue itself. |
@nick-a8c would you mind sharing your WordPress.org username so we can ensure you're properly credited in the 6.7 release next week? |
What?
Part of #59418
Requires #64786 to be merged first
Add exit animations to
Navigator
screenWhy?
An exit animation can help the user understand the transition to a new screen better — and gives an additional sense of polish to the UI.
The animation specs (durations, delays, easing functions) are also updated following the latest motion guidelines (cc @nick-a8c)
How?
useScreenAnimatePresence
hook which takes care of managing the screen's animation lifecycledata-
attributes to set animation state on the DOM element, which is used to trigger the CSS transitionsTesting Instructions
Testing Instructions for Keyboard
Screenshots or screencast
navigator-exit-animations.mp4
10x slow-motion:
navigator-exit-animations-slowmo.mp4