-
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
Adding support for defined IDs in TextControl
component
#52028
Adding support for defined IDs in TextControl
component
#52028
Conversation
This patch adds support for custom IDs in the `TextControl` component. Currently any passed ID prop is ignored, and a auto-generated value is used instead. --- Resolves WordPress#24749
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @andrewhayward! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
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.
Pending a changelog entry, this LGTM 🚀 🚢
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.
Congrats on your first PR, and thank you for adding tests! 💛
const textbox = screen.getByRole( 'textbox' ); | ||
const label = screen.getByText( labelValue ); | ||
expect( textbox ).toHaveAttribute( 'id', label.getAttribute( 'for' ) ); |
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.
Nit: Not that this is inherently wrong, but I find it more idiomatic/robust within the testing-library context to simply assert that the textbox
is accessibly labeled, rather than assert the implementation details.
const textbox = screen.getByRole( 'textbox' ); | |
const label = screen.getByText( labelValue ); | |
expect( textbox ).toHaveAttribute( 'id', label.getAttribute( 'for' ) ); | |
expect( screen.getByRole( 'textbox', { name: labelValue } ) ).toBeVisible(); |
☝️ Something like that. What do you think?
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 much experience with testing-library
, and I didn't know you could do this! That makes much more sense.
function useUniqueId( idProp?: string ) { | ||
const instanceId = useInstanceId( TextControl ); |
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.
FYI we can pass the id prefix and the idProp
directly into the useInstanceId()
function to avoid this custom code ✨
gutenberg/packages/compose/src/hooks/use-instance-id/index.ts
Lines 40 to 48 in 10d927c
/** | |
* Provides a unique instance ID. | |
* | |
* @param object Object reference to create an id for. | |
* @param [prefix] Prefix for the unique id. | |
* @param [preferredId] Default ID to use. | |
* @return The unique instance id. | |
*/ | |
function useInstanceId( |
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 noticed this, and strongly considered using it. But the useUniqueId
pattern seemed to be in quite a few places already, which made me second guess myself.
I'm quite happy to apply useInstanceId
"properly" here though, if that's actually the more appropriate direction.
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 quite happy to apply
useInstanceId
"properly" here though, if that's actually the more appropriate direction.
Yes, I think it is. I have a feeling that the existing useUniqueId
patterns were written before useInstanceId
was expanded to take three arguments.
Changing the test setup for labels to be more `testing-library` idiomatic.
Adding line item under Enhancements to include `TextControl` changes.
Dropping the old `useUniqueId` pattern in favour of the more succinct and complete `useInstanceId` usage.
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.
Great work, thank you! 🎉
Congratulations on your first merged pull request, @andrewhayward! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts: https://profiles.wordpress.org/me/profile/edit/ And if you don't have a WordPress.org account, you can create one on this page: https://login.wordpress.org/register Kudos! |
…dd/defer-script-loading-strategy * 'trunk' of https://github.com/WordPress/gutenberg: Update Changelog for 16.2.0 Adding support for defined IDs in `TextControl` component (#52028) Bump plugin version to 16.2.0 Revert "Bump plugin version to 16.2.0" Bump plugin version to 16.2.0 Add maxLength to LinkControl search items (#52523) [RNMobile] Update Editor block inserter button styles and default text input placeholder/selection styles (#52269) Site Editor: Reset device preview type when exiting the editing mode (#52566) Trim footnote anchors from excerpts (#52518) Add back old Navigation and File blocks JavaScript implementation when Gutenberg is not installed (#52553) Block Editor: Ensure synced patterns are accounted for in 'getAllowedBlocks' (#52546) Fix md5 class messed up with new block key (#52557) Fix entity cache misses for single posts due to string as recordKey (#52338) Make "My patterns" permanently visible (#52531) Hide site hub when resizing frame upwards to avoid overlap (#52180) Fix "Manage all patterns" link appearance (#52532) Update navigation menu title size & weight in detail panels (#52477) Site Editor Patterns: Ensure sidebar does not shrink when long pattern titles are used (#52547) Site Editor: Restore quick inserter 'Browse all' button (#52529) Patterns: update the title of Pattern block in the block inspector card (#52010)
What?
This PR adds support to the
TextControl
component to accept an optionalid
prop. It currently ignores them, and generates its own.Why?
As per #24749, it is sometimes useful to provide components with a defined ID (for example, if you need to reference the control with an
aria-*
attribute elsewhere). Ideally all components would work this way (but that is outside the scope of this patch).How?
Currently,
TextControl
usesuseInstanceId
to generate an ID. As with other components (seeSelectControl
, for example), this is now only used if anid
prop is not passed in. This retains backwards compatibility, and for most use-cases will have minimal impact; IDs will continue to be generated and applied.Testing Instructions
Unit tests have been added to verify the expected behaviour:
<label>
receives the ID and has a correctfor
attributeThis can also be confirmed manually:
TextControl
, providing bothid
andlabel
propsid
andfor
attributes match on the generated<input>
and<label>
respectively<label>
should put focus on the<input>
Testing Instructions for Keyboard
Although this does not impact first-line keyboard access, similar manual testing can be done using a screen reader:
TextControl
, providing bothid
andlabel
props<label>
and action it (⌃ Control + ⌥ Option + Space with VoiceOver, for example); focus should move to the<input>
<input>
and confirm that it has a label matching thelabel
prop