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 NavigatorScreen
s 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
package
URLPopover
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