wordpress/dataviews: migrate to Stack
#74174
Merged
+443
−395
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
The "how to" part of this PR could become a "migration guide from HStack/VStack to Stack" for other components. |
wordpress/dataviews: migrate to Stack
|
Size Change: +6.49 kB (+0.25%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
|
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. |
ntsekouras
reviewed
Dec 23, 2025
ntsekouras
reviewed
Dec 23, 2025
| <Stack | ||
| direction="row" | ||
| justify="end" | ||
| align="center" |
Contributor
There was a problem hiding this comment.
Why we need this? I saw some other similar additions below, so the question applies to those too 😄
Member
Author
There was a problem hiding this comment.
Because the previous HStack/VStack did too much and Stack doesn't :)
ntsekouras
reviewed
Dec 23, 2025
| > | ||
| <SettingsSection title={ __( 'Appearance' ) }> | ||
| <HStack expanded className="is-divided-in-two"> | ||
| <Stack |
Contributor
There was a problem hiding this comment.
I'm just checking the code first and will test the UI, but I'm curious about the expanded prop migration. Before it was set as default and added some width/height styles:
height: isColumn && expanded ? '100%' : undefined,
width: ! isColumn && expanded ? '100%' : undefined,
So, at first reading I'd expect some additions to every usage that used the default or like here set it explicitly to true.
ntsekouras
reviewed
Dec 23, 2025
| } | ||
|
|
||
| .dataviews-controls__date-range-inputs > * { | ||
| min-width: 0; |
Contributor
Member
There was a problem hiding this comment.
I actually couldn't figure out what this min-width is intended for. Nothing changes?
CleanShot.2025-12-24.at.04-18-38.mp4
Member
Author
There was a problem hiding this comment.
It was for this situation (note how the inputs overflow the container):
Member
There was a problem hiding this comment.
Ah ok. Yeah we definitely can't add a style like that at the Stack level, and it's probably unsafe for this specific instance, too. This is in Firefox:
Maybe change the layout so it spans two lines, or widen the popover?
ntsekouras
reviewed
Dec 23, 2025
ntsekouras
reviewed
Dec 23, 2025
ntsekouras
reviewed
Dec 23, 2025
ntsekouras
reviewed
Dec 23, 2025
packages/dataviews/src/components/dataviews-view-config/properties-section.tsx
Outdated
Show resolved
Hide resolved
Contributor
|
I've left some comments but in my testing (and the code review) this seem fine. If we don't have visual regressions, I think we can address the components (Stack) related questions separately and not block this PR. |
2c14451 to
284aecf
Compare
|
Flaky tests detected in 284aecf. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20465068389
|
mirka
reviewed
Dec 23, 2025
Member
mirka
left a comment
There was a problem hiding this comment.
We've been thinking about the expand prop, and I'm personally reluctant to support something similar for the new Stack. Stack is a flex container, but it's not guaranteed to be a flex child in all situations. It's relevant to note that the original HStack/VStack components were designed back when flexbox wasn't even fully supported on our browserslist requirements. So it was a simpler time, and a big part of its appeal was mimicking flex-like behaviors.
| @@ -1,3 +1,5 @@ | |||
| @use "@wordpress/theme/src/prebuilt/css/design-tokens.css" as *; | |||
Member
There was a problem hiding this comment.
Similar to how I think the DataViews package is externalizing the @wordpress/components stylesheet, we probably want to externalize the @wordpress/theme stylesheet as well. Meaning, it's the consumer's responsibility to ensure that the stylesheet is added somewhere in their app. This is to prevent duplication of the stylesheet in the final app bundle.
We will also be doing this for the @wordpress/ui package. We'll add it as a stylesheet dependency in Storybook, and document it in the package readme (#73938).
| } | ||
|
|
||
| .dataviews-controls__date-range-inputs > * { | ||
| min-width: 0; |
Member
There was a problem hiding this comment.
I actually couldn't figure out what this min-width is intended for. Nothing changes?
CleanShot.2025-12-24.at.04-18-38.mp4
Contributor
|
Just want to mention that we should ensure that I think for the Stack component it's ok because it's a component without any actual visible colors or things like that, but it might not be the case for controls... so we need to be careful there. |
Member
|
The current plan is for Fortunately I think style dependency issues will be pretty noticeable in Storybook, since each package needs to declare all their stylesheet dependencies explicitly there. |
Contributor
I think |
Member
|
The idea of automatically including the design tokens stylesheet when using any
I'm not sure I follow what we'd expect to break with this? If we're planning to enqueue the design tokens stylesheet in most WordPress page contexts, what's going to break in how people use DataViews? Although to the broader point and to @mirka's comment in #74174 (comment), I think outside the WordPress context it may be a reasonable expectation (with precedent) that consumers would need to ensure the prerequisite stylesheets are available. Edit: Another possibility could be to embed all default CSS properties to be defined by |
Contributor
|
Let's see how it evolves and keep an eye on feedback from folks already using DataViews. It's also possible that I'm overthinking this a bit. |
This was referenced Jan 13, 2026
Member
|
I created a related issue for stylesheet management at #74594 . Although re-reading this discussion, I'm not fully convinced we're on the same page 😅 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR migrates from HStack/VStack (wordpress/components) to Stack (wordpress/ui package).
Why?
To give early feedback on the new Stack component.
How?
Migration Guide: HStack/VStack to Stack
Overview
This guide covers migrating from HStack/VStack components in @wordpress/components to the unified Stack component from @wordpress/ui.
Import Changes
Before
After
Component Mapping
<HStack><Stack direction="row"><VStack><Stack direction="column">Prop Changes
Direction
Spacing → Gap
The spacing numeric prop maps to semantic gap tokens:
Alignment
Wrap
Removed Props
Unchanged Props
Examples
HStack Basic
VStack Basic
HStack with expanded={false}
With wrap
Notes
Testing Instructions