Skip to content

Conversation

@jameskoster
Copy link
Contributor

What?

  • Introduces independent spacing controls for DataForm layouts:
    • Regular layout: spacing between individual fields (default 4).
    • Card layout: spacing between consecutive cards (default 6).
  • Added spacing to RegularLayout, CardLayout, and their normalized types.
  • Applied layout-specific wrappers so each layout’s spacing is respected.
  • Updated LayoutMixed story to use layout: { type: 'card', spacing: 6 }.

Why?

  • Previously, one spacing setting controlled both field spacing and card spacing, preventing independent tuning.
  • Enables tighter spacing inside cards while keeping larger gaps between cards (or vice versa) per design needs.

How?

  • Types
    • Updated packages/dataviews/src/types/dataform.ts to add spacing to RegularLayout and CardLayout, and to normalized variants.
  • Normalization
    • Updated packages/dataviews/src/dataform-layouts/normalize-form-fields.ts to:
      • Default regular spacing to 4.
      • Default card spacing to 6.
      • Preserve user-supplied spacing.
  • Rendering
    • packages/dataviews/src/dataform-layouts/index.tsx: Added wrappers for regular and card that render a VStack with layout.spacing.
    • packages/dataviews/src/dataform-layouts/data-form-layout.tsx: Default wrapper now respects layout.spacing.
  • Stories
    • packages/dataviews/src/stories/dataform.story.tsx: LayoutMixedComponent now sets layout: { type: 'card', spacing: 6 }.

Testing

Note

I had assistance from AI preparing this PR. Apologies if anything was butchered, but hopefully it communicates the idea and can serve as a starting point.

@jameskoster jameskoster added [Type] Enhancement A suggestion for improvement. [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Oct 10, 2025
@jameskoster jameskoster requested review from gigitux and oandregal and removed request for oandregal October 10, 2025 14:38
@github-actions
Copy link

github-actions bot commented Oct 10, 2025

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: dinhtungdu <dinhtungdu@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions
Copy link

github-actions bot commented Oct 10, 2025

Flaky tests detected in 6615830.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18741236975
📝 Reported issues:

Copy link
Member

@dinhtungdu dinhtungdu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Codewises, it looks good to me. I can confirm the change in the updated story, too. Can you please update the DataViews readme file to mention the new spacing prop we're adding here?

* Spacing between individual fields when using the regular layout.
* Defaults to 4.
*/
spacing?: number;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to have different spacing per layout, do we also want the consumer to be able to change this setting? It's fine if we want, just checking because I thought we didn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it hurts so long as we have smart defaults. I could see this being a foundation for a density option in the future. For example in the Block inspector we might want fields to be closer together than in admin settings pages because the container sizes are so different. It would be neat to have a system for handling that. Not a strong feeling though if we prefer to leave it out for now...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use cases you mention make sense, but it could also be automatic based on viewport size or some other trick? I worry that if we expose this setting, every screen that uses DataForm would use a different spacing. It's not a strong opinion, and I'll defer to you. If it's not something we immediately need, we can add it later for consumers to use (it's more difficult to remove it, even if we have breaking changes).

@jameskoster
Copy link
Contributor Author

@oandregal I updated the spacing values but removed the ability for consumers to customise. Please feel free to push any changes in case anything is wrong.

@oandregal oandregal force-pushed the update/dataform-spacing branch from e5b4bf9 to 97c0e0b Compare October 20, 2025 15:39
} ) => (
<VStack
className="dataforms-layouts__wrapper"
spacing={ ( layout as any )?.spacing ?? 4 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, https://github.com/WordPress/gutenberg/pull/72284/files#diff-1d824e9459e5eecc174c60bb790d3f6c5eb5bb4f83fb01ffe5e737bb91facb71R24 introduced some spacing prop already. It didn't work because the normalizedLayout didn't have them, so it's fine to remove them from here without considering a breaking change. cc @dinhtungdu for awareness.

Copy link
Member

@oandregal oandregal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unable to test the storybook right now because there's an issue with it. Though the code respects the intent (setting custom spacing per layout).

@oandregal oandregal changed the title Make DataFormLayout spacing customisable DataForm: set specific spacing per layout Oct 20, 2025
@oandregal oandregal changed the title DataForm: set specific spacing per layout DataForm: set spacing for regular and card layouts Oct 20, 2025
@oandregal oandregal force-pushed the update/dataform-spacing branch 2 times, most recently from 76bc622 to f657511 Compare October 21, 2025 08:01
@jameskoster
Copy link
Contributor Author

Thank you for taking this over @oandregal ❤️

@oandregal oandregal force-pushed the update/dataform-spacing branch from f657511 to 4c50413 Compare October 23, 2025 07:41
@oandregal oandregal enabled auto-merge (squash) October 23, 2025 07:41
@oandregal oandregal merged commit 8696b08 into trunk Oct 23, 2025
41 of 43 checks passed
@oandregal oandregal deleted the update/dataform-spacing branch October 23, 2025 10:11
@github-actions github-actions bot added this to the Gutenberg 22.0 milestone Oct 23, 2025
@jameskoster jameskoster added the Backport to WP 6.9 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Oct 23, 2025
@github-actions
Copy link

There was a conflict while trying to cherry-pick the commit to the wp/6.9 branch. Please resolve the conflict manually and create a PR to the wp/6.9 branch.

PRs to wp/6.9 are similar to PRs to trunk, but you should base your PR on the wp/6.9 branch instead of trunk.

# Checkout the wp/6.9 branch instead of trunk.
git checkout wp/6.9
# Create a new branch for your PR.
git checkout -b my-branch
# Cherry-pick the commit.
git cherry-pick 8696b081078b15c330a45fb54f0ac0d556da21fc
# Check which files have conflicts.
git status
# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue
# Push the branch to the repository
git push origin my-branch
# Create a PR and set the base to the wp/6.9 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

@t-hamano
Copy link
Contributor

There was a conflict, and it couldn't be backported to the wp/6.9 branch. If this PR is needed for the 6.9 release, could you submit a PR for manual backport?

@oandregal
Copy link
Member

Prepared the backport at #72656

oandregal added a commit that referenced this pull request Oct 24, 2025
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
@t-hamano
Copy link
Contributor

This pull request was manually backported to the wp/6.9 branch: #72656

@t-hamano t-hamano removed the Backport to WP 6.9 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond [Type] Enhancement A suggestion for improvement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants