UI: Derive Base UI direction from WordPress i18n - #80399
Conversation
|
Size Change: +1.07 kB (+0.01%) Total Size: 7.65 MB 📦 View Changed
|
|
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. |
|
Flaky tests detected in 46e00a0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29566702065
|
mirka
left a comment
mirka
left a comment
There was a problem hiding this comment.
Would it be better if we just pre-wrapped all the affected Root subcomponents in wp-ui and hooked in the @wordpress/i18n isRTL() value?
I fear it would be a tall order to ask consumers to set up yet another thing for the package to work. And unlike theming, people will need to be testing specifically for RTL behavior to even notice that it isn't working out of the box.
jsnajdr
left a comment
jsnajdr
left a comment
There was a problem hiding this comment.
In WordPress we have the @wordpress/i18n imports, even the ui library already uses __. They are mostly used without any reactivity:
import { __, isRTL } from '@wordpress/i18n';
function Compo() {
return <div className={ isRTL() ? 'r' : 'l' }>{ __( 'Hello' ) }</div>
}If we export DirectionProvider, we are adding a second API for the same thing. Only the BaseUI components really need this.
Wrapping every BaseUI component with a DirectionProvider is a solution, but it adds a lot of noise to the React tree.
| import { DirectionProvider as _DirectionProvider } from '@base-ui/react/direction-provider'; | ||
| import type { ComponentProps } from 'react'; | ||
|
|
||
| type DirectionProviderProps = ComponentProps< typeof _DirectionProvider >; |
There was a problem hiding this comment.
This type is exported as _DirectionProvider.Props
46e00a0 to
fdfde28
Compare
ciampo
changed the title
fdfde28 to
6263a07
Compare
* DirectionProvider: Add UI wrapper * DirectionProvider: Add changelog entry * UI: Derive Base UI direction from i18n --- Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: mirka <0mirka00@git.wordpress.org> Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Apologies for a very late reply but yes, I'm pleasantly surprised that the suggestion to wrap everything with |
3 participants
Extracted from #79560.
What?
Makes the direction-sensitive
@wordpress/uicomponents automatically use WordPress's text direction. This coversAutocomplete,Combobox,Popover,Select,Tabs, andTooltip.Why?
Base UI defaults its internal direction context to LTR. WordPress already exposes the current text direction through
@wordpress/i18n, so consumers should not need to add and forward a second public provider.How?
isRTL().Rootcomponents whose Base UI internals consume direction.Testing Instructions
npm run storybook:dev.Tabsstory and use the toolbar to switch the direction global between LTR and RTL.Popover,Tooltip,Select,Combobox, andAutocompletestories. Confirm their positioned content follows the direction global without extra provider setup.Testing Instructions for Keyboard
Tabsstory, press Tab until a tab receives focus.Use of AI Tools
This PR was prepared with AI assistance in Codex and reviewed locally.