-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
CustomSelectControl V2: fix setting initial value and reacting to external controlled updates #62733
Conversation
Size Change: 0 B Total Size: 1.76 MB ℹ️ View Unchanged
|
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. |
@@ -64,7 +64,7 @@ const ControlledCustomSelectControl = ( { | |||
onChange: onChangeProp, | |||
...restProps | |||
}: React.ComponentProps< typeof UncontrolledCustomSelectControl > ) => { | |||
const [ value, setValue ] = useState( options[ 0 ] ); | |||
const [ value, setValue ] = useState( restProps.value ?? options[ 0 ] ); |
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.
This change allows the Controlled
version of the component to use the value
prop as the initial value (the same change was applied to the v1 component)
94b6f07
to
b0c11f0
Compare
onChange={ mockOnChange } | ||
/> | ||
); | ||
render( <Component { ...props } onChange={ mockOnChange } /> ); |
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.
Align the test with the legacy v2 adapter (which doesn't set the value
prop)
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.
This looks and works well for me, also by following the test instructions in #62308! 👍
Thanks for adding some tests 🚀
I've left some minor suggestions, but nothing seems to be blocking, so take them as optional ones.
packages/components/src/custom-select-control-v2/legacy-component/test/index.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/custom-select-control-v2/legacy-component/test/index.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/custom-select-control-v2/legacy-component/test/index.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/custom-select-control-v2/legacy-component/test/index.tsx
Outdated
Show resolved
Hide resolved
expect.objectContaining( { | ||
inputValue: '', | ||
isOpen: false, | ||
selectedItem: expect.objectContaining( { | ||
name: 'aquamarine', | ||
} ), | ||
type: '', | ||
type: expect.any( String ), |
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.
type
will literally always be an empty string, though?
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.
It will, but since we don't really document it in the v1, I thought that tests should be generic about what value to expect — as far as the attribute exists and it's a string. This also allows for the v1 and legacy v2 unit tests to be aligned on this particular assertion
expect.objectContaining( { | ||
inputValue: '', | ||
isOpen: false, | ||
selectedItem: expect.objectContaining( { | ||
name: 'aquamarine', | ||
} ), | ||
type: '__item_click__', | ||
type: expect.any( String ), |
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.
To make sure I understand this change: it's for compatibility so the both versions of the tests would have the same expectation against the different implementations?
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.
Yup! See reply in #62733 (comment)
b0c11f0
to
c5b6a4c
Compare
All feedback addressed (either with code changes or replies). Will merge when CI checks pass. Thank you @tyxla for the review! |
Flaky tests detected in c5b6a4c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9616335298
|
What?
Supersedes #62308
Depends on #62255
Fixes how the
CustomSelectControlV2
legacy adapter behaves around its initial value (and consequent firing of theonChange
callback)Why?
How?
Pass explicit
value
anddefaultValue
to theuseStore
call in the legacy adapter. This has two consequences:value
explicitly, we fix the controlled updates bugdefaultValue
explicitly to the first option, we don't rely on Ariakit's internal automatic selection and thus we avoid firing theonChange
callback on initial renderI edited existing unit tests and added a few more in both the v1 and the v2 legacy adapter to cover those changes and ensure that the two components behave the same.
Testing Instructions
packages/components/src/custom-select-control-v2/legacy-component/index.tsx
Additionally, check testing instructions from #62308