This post lists notable changes to the @wordpress/components package for the WordPress 6.4 release
Table of Contents
Making Popover.Slot optional
As part of a wider effort to streamline the developer experience of using Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ as a platform/framework to build block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editors, the Popover component has been tweaked so that it’s not necessary anymore to manually specify a Popover.Slot component (and a SlotFillProvider) somewhere in the React React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. tree.
The Popover component now works out of the box, and the Popover.Slot component can be optionally used to tweak where the popover should render in the DOM tree.
A side-effect of this change is that some instances of Popover may not render inline anymore when a Popover.Slot is not rendered on the page, affecting both the popover’s DOM position and the styles inherited via the CSS Cascading Style Sheets. cascade. To mitigate this use case, a new inline prop has been added to the Popover component, to force the component to render inline, thus preserving the legacy behavior.
For more information visit #53889, #53982, and #54912. (top)
The Tooltip and the TabPanel components have been completely rewritten to leverage third-party, headless libraries (specifically ariakit) as the first tasks of a new experimental effort within the package.
Both migrations were intentionally designed to avoid changes to the API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. or developer experience, while also bringing several benefits:
- better compliance with semantics, accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) requirements, and related WAI-ARIA patterns;
- better user experience thanks to using a widely used, well-tested underlying implementation;
- better types and improved unit tests;
- less maintenance required in the long term.
Specifically to the Tooltip component, the refactor also fixed a long-standing issue and presented the opportunity to align with other components already using a new placement prop in lieu of the legacy, now deprecated position prop.
For TabPanel, the only noteworthy change is that tabpanel elements now get a tabstop. This means that when focused on a Tab, pressing the [Tab] key will apply focus to the tabpanel itself, rather than jumping directly to the next focusable element within the tabpanel element.
As mentioned above, this was part of an experiment around using third-party libraries more deliberately in the components package. In the future, we may look at more opportunities for such rewrites, especially for components with more complex semantics and accessibility implementations.
For more information visit #48440, #54264, #54406, and #52133. (top)
New props for the Modal component
The Modal component has been enhanced with a couple of additions to its APIs. Thanks to a new headerActions prop, developers using the Modal can inject buttons (and other elements) into the Modal‘s header The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., next to the close button.
The focusOnMount prop has also received an update, and it now accepts a new "firstContentElement" option. When setting focusOnMount="firstContentElement", the Modal component will try to focus on the first tabbable element within the Modal‘s content (ie. the markup passed via the children prop).
This is different from the pre-existing "firstElement" option, which causes focus to go to the first element anywhere within the Modal, including its header (usually the close button).
Note that it is the responsibility of the developer to ensure that, when focusOnMount="firstContentElement", there is at least one tabbable element within the Modal‘s children.
For more information visit #53328 and #54590. (top)
Improving size consistency for UI User interface components
UI components across the editor (input fields, buttons, etc) are currently rendering in a range of heights between 30px and 40px. In order to add consistency and visual polish to the editor’s UI, we started working on standardizing components toward having a default height of 40px.
To ensure a smooth transition to the new default sizes, we have started to introduce a new, temporary __next40pxDefaultSize prop on selected components around the codebase, which will allow consumers to start opting into the new default size. Sometime after that, the temporary prop will be deprecated and ultimately removed, causing _all_ instances of the components to switch to the default 40px size out of the box.
To start opting into the new 40px default height, set the __next40pxDefaultSize prop to true:
<Button __next40pxDefaultSize>
Code is poetry
</Button>
So far, the components exposing the new temporary __next40pxDefaultSize prop are:
For more information visit #46734 and #46741. (top)
More granular control of decimal places on NumberControl-based components
A new spinFactor prop has been added to NumberControl, allowing consumers of the components to specify by how much should the input’s value increment/decrement with respect to the step. This is particularly useful when more granular control is needed (thus allowing for more decimal places and a smaller step) but without sacrificing the UX User experience around manually incrementing/decrementing the value.
Even if the prop was added to NumberControl, all components based on NumberControl can benefit from this change — this includes, for example, UnitControl and LineHeightControl.
For more information visit #52902. (top)
Rendering CircularOptionPicker as a listbox by default
To improve CircularOptionPicker‘s semantics and keyboard navigation, the component has been tweaked to render and behave as a listbox by default. This change also causes the component to become a single tab stop, with the individual color options accessed using arrow keys.
In the (few) instances in which it makes sense for CircularOptionPicker to still render as a list of individual buttons, consumers of the component can use the asButtons prop to switch back to the legacy behavior.
For more information visit #52255 and #54290. (top)
A new tokenizeOnBlur prop has been added to FormTokenField, causing the component to tokenize its current input instead of discarding it when losing focus.
This is particularly useful when FormTokenField is used in places like modals, where the user may press a button causing the modal to close and FormTokenField to lose focus before its input could be tokenized.
For more information visit #54445. (top)
Controlling open/closed state of Dropdown and DropdownMenu
The open/closed state of the Dropdown and DropdownMenu components can now be controlled by their consumers via the open, onToggle and defaultOpen props, allowing more flexibility and more advanced behaviors when using these components.
For more information visit #54257. (top)
Props to @brookemk, @tyxla and @shireling for the help in writing these dev notes Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
Props to @bph and @webcommsat for reviews
#6-4, #dev-notes, #dev-notes-6-4
