BoxControl: Add support for presets

[youknowriad]

Related #67625

What?

This PR implements "presets" support in the BoxControl component (borrowing the behavior from the spacing sizes with some subtle differences)

• When the presets are provided, there's a button to switch between a custom value and a preset value.
• A range control is used always for presets (this is to allow iteration, in the next PR I'll add a Select control for long presets)
• If I switch back and forth between presets and custom value, I don't try to "guess" the value from the preset or the opposite, this is a conscious decision because for me, setting a preset who's current value is 4px is different than setting 4px custom value. The preset value can change over time.
• I added a storybook story to try this

Testing Instructions

• Run storybook locally npm run storybook:dev
• You can check the "BoxControl with presets" story.

[github-actions]

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: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@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]

Flaky tests detected in a0c5d29.
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/12294409796
📝 Reported issues:

• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[ntsekouras]

This looks good in general. I've left just a few small suggestions/questions. Thanks!

[jorgefilipecosta]

When I select a preset e.g: Medium and then switch to "Set custom size" I would expect the field to have the value of the preset (8px), but it becomes empty.

I disagree and I explained this in the description as well. Choosing a preset is different than setting a custom value. The present is a dynamic value that changes over time, so the user should be able to set a specific 8px or a dynamic preset whose current value is 8px and these two things are not the same.

I understand your point. However, I believe that when a preset is selected and then the user switches to the custom option, the current value should still display as 8px, even though a preset is being used. This would help users see the value that is currently applied, making it easier to make smaller adjustments. Without this visibility, I might struggle to decrease the margin slightly since I wouldn’t know the exact value set with the presets, and there is no easy way to just decrease 1px.

We could differentiate the handling of values by storing a different value when 8px is chosen as a custom value versus when it is selected as a preset. Although they may appear the same, they should be stored differently to reflect user intent. I think this solution addresses your concern.

We also need to decide whether switching to custom should trigger an onchange event that changes the displayed value from the preset notation to the custom notation (which includes the value). Alternatively, we could show the custom value but keep it stored as a preset until the user makes additional adjustments. I am fine with either option.

This discussion is connected to the effort of displaying global styles values at the block level. We aim to show these values even if the block itself has no styles applied and only inherits them from global styles.

This is a personal preference and not a blocker for the pull request.

[youknowriad]

I understand your point. However, I believe that when a preset is selected and then the user switches to the custom option, the current value should still display as 8px, even though a preset is being used. This would help users see the value that is currently applied, making it easier to make smaller adjustments. Without this visibility, I might struggle to decrease the margin slightly since I wouldn’t know the exact value set with the presets, and there is no easy way to just decrease 1px.

Do you think the user would understand that "touching" the field from 8px and just removing and adding the same character back switches from "preset value" to "custom value"? I think that might be more confusing.

I agree though that both options have downsides, although both options are possible. I think right now in this PR, we're just adding support for "presets" to a component that is not used, so this is not going to have an impact immediately but I think we should keep this discussion open with designers as well @jasmussen @jameskoster. Especially, in my follow-up PRs where I'll be replacing the custom components with BoxControl

[jorgefilipecosta]

This is working well, and @youknowriad clarified the concerns I had 👍

[jameskoster]

From my experience, the behavior Jorge describes is quite common, particularly when detaching from presets. Here's an example from Figma that I use all the time:

detach.mp4

Agree there are trade-offs both ways, but this approach feels a bit more standard to me.

[youknowriad]

@jameskoster I agree that with the "detach" button, the behavior you're showing the best one. I think we can explore the detach button separately but right now it doesn't exist anywhere in the UI AFAIK

[jameskoster]

Yes fair enough. I guess it's a question of whether the button is about detaching or setting a custom value. Personally I think detaching has it's uses–many of which Jorge outlined above–and is a precursor to setting a custom value anyway. Though I appreciate the existing UI focuses more on the latter.

I'll open an issue.

[jameskoster]

Actually @youknowriad it does exists 🙊

size.mp4

Notice how toggling to set a custom value after selecting a preset font size, the size value/unit remains.

[youknowriad]

@jameskoster you misunderstood what I'm saying, Yes, we do keep the value visible but we don't have the "unlink" button which means there's no way for the user to understand whether the value that is visible in the custom input is actually "linked" or not "linked" to the preset.

So in the screenshot you shared, the value is "linked" but the user doesn't know it, the only way to "unlink" it but keep the same value is to actually type some random character in the input and remove it.

[jameskoster]

Oh wow, I see what you mean. TIL that switching to set a custom value doesn't unlink from the preset until you also change the value. I guess it's a small detail but this behavior feels unexpected to me.

[ciampo]

A bit late to the conversation, but my preference would be:

• when moving from preset to custom, the value is not lost. But the component should know the difference between "8px as a preset value" and "8px as a custom value"
• when moving from a custom value to a preset:
  • if the custom value matches one of the presets, such preset gets selected
  • if there isn't a custom match, we could display a literal "custom" option, until the user picks a preset

The FontSizePicker already does something similar when displaying a SelectControl instead of a ToggleGroupControl where there are many font sizes:

Kapture.2024-12-13.at.16.42.10.mp4

In any case, whatever UX we think is the best, we should apply uniformly across all UI components

[ciampo]

Potential improvements for Developer Experience:

• a runtime check, warning when only one of the two presets and presetKey props are defined
• conditional types, specifying that presetKey is not optional if the presets prop is specified