Block Editor: Improve act() usage in BlockSwitcher tests
#46227
Closed
Conversation
This file contains 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
tyxla
added
[Type] Code Quality
tyxla
requested review from
Mamaduka,
youknowriad,
jsnajdr,
flootr and
ntsekouras
|
Size Change: 0 B Total Size: 1.32 MB ℹ️ View Unchanged
|
jsnajdr
approved these changes
Dec 1, 2022
| @@ -15,13 +15,22 @@ import { copy } from '@wordpress/icons'; | |||
| * Internal dependencies | |||
| */ | |||
| import { BlockSwitcher, BlockSwitcherDropdownMenu } from '../'; | |||
| import { act } from 'react-test-renderer'; | |||
There was a problem hiding this comment.
Oh, we didn't remove all of them yet? 🙂
There was a problem hiding this comment.
I think some of those fixes got lost in the thousand rebases 😅 We'll clean them up, don't worry.
| name: 'Block Name', | ||
| } ); | ||
|
|
||
| expect( menu ).not.toBeVisible(); |
There was a problem hiding this comment.
This .not.toBeVisible() check points at another thing a reliable test should watch for. The menu is invisible not because the popover is not yet positioned, but because its appearance is animated with framer-motion. At the very beginning the popover has opacity: 0.
The animation and positioning are completely independent from each other.
| expect( menu ).toBeInTheDocument(); | ||
| expect( menu ).not.toBeVisible(); | ||
| expect( menu ).toBeVisible(); |
There was a problem hiding this comment.
At this moment, if you check it with a snapshot, the opacity is not yet 1, but "only" 0.9994. There is an animation frame loop (in framer-motion) that gradually changes it from 0 to 1. At the moment of this check, i.e., after we're finished waiting for popover positioning, the animation hasn't finished yet.
We should do another wait with:
await waitFor( () => expect(popover).toHaveStyle( { opacity: 1 } );Or integrate it into toBePositionedPopover? Making it do a toBePositionedAndFullDisplayedPopover?
There was a problem hiding this comment.
Yep, I was thinking about that. I think this is a worthy improvement, let me work on it.
There was a problem hiding this comment.
Okay, this is interesting. I haven't debugged thoroughly yet, but the moment I add the assertion you mentioned, or extend .toBePositionedPopover() to check for opacity: 1, I get the act warnings again!
There was a problem hiding this comment.
I debugged this and the act() warning is caused by this setHasAnimatedOnce state update:
gutenberg/packages/components/src/popover/index.tsx
Lines 120 to 123 in 5fcf00d
When framer-motion is finishing an animation, it will set the final opacity: 1 style, then will resolve a promise, and then there's a .then( () => props.onAnimationComplete() ) handler. The state update runs one promise tick after the waitFor for opacity: 1 has finished.
@ciampo I'm curious what are we preventing with this hasAnimatedOnce guard? My understanding is that with a <motion.div animate={ { opacity: 1 } }>, the animate animation runs only once, on mount, and then never again. But a code comment suggests that it runs also on "subsequent prop changes"? What kind of change exactly can re-trigger the animate animation to run again?
If Popover didn't have the hasAnimatedOnce state, waiting for .toHaveStyle( { opacity: 1 } ) would work flawlessly.
There was a problem hiding this comment.
Hey @jsnajdr , if I recall correctly that state variable is in place to avoid the animation from re-running when the placement changes, as this inline comment says:
gutenberg/packages/components/src/popover/index.tsx
Lines 109 to 112 in b120213
If I remember correctly, without this flag, the animation would run again if the value of the placement prop (and probably other props too) change.
Feel free to play around with it and remove it if we find a better solution to the problem!
There was a problem hiding this comment.
without this flag, the animation would run again if the value of the
placementprop (and probably other props too) change.
This is however not true, at least with the version of framer-motion that we're using now. The animate animation runs only on mount, never anywhere else, like on a prop change. When placement changes, then via placementToMotionAnimationProps the value of the animate prop changes, too, but that doesn't restart the animation either.
I verified that when debugging framer-motion back in December, and also experimentally. On this video, the block inserter popover appears with animation (I made it run slower to make it more visible), but then the switches between top and bottom placements are not animated any more:
I think we can either remove hasAnimatedOnce completely, or use it just to set the is-positioned class (meaning that the popover has finished positioning and animating).
There was a problem hiding this comment.
Sounds good to me, then! Please do ping me on the PR if you're going to work on it, happy to help with reviewing and testing.
|
As recognized, there are some flaws with this approach, it's not reliable enough to check if a popover is positioned the way we do. I'll reconsider the approach in another PR. |
This was referenced Dec 5, 2022
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.
What?
This PR improves the
act()usage inBlockSwitcherto make the tests more precise and more expressive.Why?
As part of the React 18 upgrade in #45235, we added a bunch of
act()calls that could be improved and made more specific.How?
Instead of going with
await act( () => Promise.resolve() ), we change the test to wait for the popover to be positioned before continuing.Testing Instructions
Verify tests still pass:
npm run test:unit block-editor/src/components/block-switcher/test/index.jsTesting Instructions for Keyboard
None
Screenshots or screencast
None