This post lists notable changes to the @wordpress/components package for the WordPress 6.2 release:
Deprecating bottom margin on control components
Several UI User interface components currently ship with styles that give them top and/or bottom margins. This can make it hard to reuse them in arbitrary layouts, where you want different amounts of gap or margin between components.
To better suit modern layout needs, we will gradually deprecate these outer margins. A deprecation will begin with an opt-in period where you can choose to apply the new margin-free styles on a given component instance. Eventually in a future version, the margins will be completely removed.
Continuing the effort started in previous releases, for the WordPress 6.2 release we focused on the BaseControl component and its consumers. While the effort is still ongoing, the outer margins on the following components have been deprecated. (Links all go to the WordPress Storyboard)
To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true.
<SelectControl
options={ selectOptions }
value={ selectValue }
label={ __( 'Label' ) }
onChange={ onSelectChange }
__nextHasNoMarginBottom={ true }
/>
To better suit modern layout needs, we will gradually deprecate these outer margins. A deprecation will begin with an opt-in period where you can decide to apply the new margin-free styles on a given component instance. Eventually, in a future version, the margins will be completely removed.
In WordPress 6.2, the bottom margin on the URLInput component has been deprecated.
To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true:
<URLInput
__nextHasNoMarginBottom
className={ className }
value={ attributes.url }
onChange={ ( url, post ) => setAttributes( { url, text: (post && post.title) || 'Click here' } ) }
/>
Contributors working on the Components package are in the process of migrating all internal usages to use the new __nextHasNoMarginBottom prop. Once all usages are migrated, an official deprecation will be added to the BaseControl component.
For more information visit #38730. (top)
Increased consistency when applying inline styles and class names to control components
To improve consistency across the @wordpress/components package, any inline styles passed to the InputControl component through its style prop will be applied to its outer wrapper element, instead of an inner input wrapper element.
Similarly, any class names applied to the UnitControl component through its className prop will be applied to its outer wrapper element, instead of an inner input wrapper element. As a consequence of this change, the components-unit-control-wrapper class name and the __unstableWrapperClassName prop have been removed from the UnitControl component.
These changes may affect usages of other components relying on InputControl and UnitControl, such as NumberControl, RangeControl, HeightControl, etc.
For more information visit #45340 and #45139. (top)
Parent navigation support & named arguments for the Navigator component
The Navigator component from the @wordpress/components package has been enhanced with two additional features:
- it can now match named arguments (ie.
/product/:productId);
- it now offers a way to navigate to the parent screen via the
goToParent function and the NavigatorToParentButton component.
These two features assume that NavigatorScreens are assigned paths that are hierarchical and follow a URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org-like scheme, where each path segment is separated by the / character.
For more information visit #47827 and #47883. (top)
Absence of inert polyfill
The Disabled component internally relies on the inert property. To manage expectations when interacting with the component in browsers where the inert attribute is not supported, the component’s docs were updated to clarify that the polyfill for the inert property needs to be added by the consumer of the @wordpress/components package.
For more information visit #45272. (top)
Using the placement prop for Popover-based components
With the recent refactor of the Popover component to use the floating-ui library, the placement prop has become the recommended way to determine how the component positions with respect to its anchor. While the older position prop is still supported, we’re making changes towards removing all of its usages in the 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/ repository and deprecating it.
As part of these efforts, the position prop has been marked as deprecated on the following components:
Dropdown from the @wordpress/components packageURLPopover component from the @wordpress/block-editor package
Consumers of these components should be using the new placement prop instead.
For more information visit #46865 and #44391. (top)
Added default values to props on ColorPalette, BorderBox and BorderBoxControl
Many props of the ColorPalette, BorderBox and BorderBoxControl components from the @wordpress/components package have been assigned a default value to better reflects each prop’s purpose.
The Storybook pages for each component have been updated: ColorPalette, BorderControl and BorderBoxControl to reflect those changes.
For more information visit #45463. (top)
__experimentalHasMultipleOrigins removed from selected components
The __experimentalHasMultipleOrigins prop has been removed from the ColorPalette, GradientPicker, BorderControl and BorderBoxControl components in the @wordpress/components package.
The prop has been replaced by a check in the ColorPalette component which automatically detects whether the colors passed through the colors prop has a single or multiple color origins.
For more information visit #46315. (top)
Props to @0mirka00 and @brookemk 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 reviewing this post.
#6-2, #dev-notes, #dev-notes-6-2
You must be logged in to post a comment.