Repository navigation
Conversation
Form field descriptions were restricted to strings even though field descriptions accepted React elements and card layouts rendered them directly. Match both form field types to the field API so card descriptions can contain links and other React elements.
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
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. |
|
Size Change: 0 B Total Size: 7.75 MB |
|
Flaky tests detected in fcf3e38. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/30389182232
|
| id: string; | ||
| label?: string; | ||
| description?: string; | ||
| description?: string | ReactElement; |
There was a problem hiding this comment.
We had a discussion about this with @oandregal here, so we shouldn't have non-serializable values.
I'm not sure if there is a good way to support richer descriptions in forms. We could probably support some elements like links etc.. by describing in a serializable format and then use createInterpolateElement? 🤔
e.g.
description?: string | {
text: string;
links?: Record< string, { href: string } >;
};
There was a problem hiding this comment.
I like the looking for solutions, though I'm not convinced we should create an API for links here.
If we ever wanted to support ReactElement here, we'd need to think about how consumer could filter the form data from the server (view config API) — which is now a PHP filter, and would need to be a different thing if we supported JavaScript.
There was a problem hiding this comment.
Thank you for the context, folks! So I think we should create a serializable signature that can be filtered server-side but still provide a rich field on the front end. So instead of just links, we can have an elements object:
description?: string | {
text: string;
elements?: Record< string, RichElement >;
};
type RichElement =
| { type: 'link'; href: string; target?: '_self' | '_blank'; rel?: string }
| { type: 'emphasis' } | { type: 'strong' } ;I think this matches the API used in other parts of the codebase (1, 2). WDYT, @oandregal / @ntsekouras ?
There was a problem hiding this comment.
TBH even if we try to have some kind of API like createInterpolateElement it would still be quite limited and probably not worth it.
@elazzabi a workaround (hack) is to have a pseudo-field, readonly as the first field without showing the label. It's not ideal, but would that unblock your project for now?
There was a problem hiding this comment.
@ntsekouras, gotcha! I'll note the limitation, and we'll try to work with pseudo-fields for now. I think the biggest drawback is that the descriptions will not show in the closed card state (since those are fields now). However, we'll see if we can show normal non-rich fields when the card is closed, then fall back to pseudo-fields when it's open.
|
Closing this PR after the discussion in this comment. |
What?
Allows DataForm field descriptions to contain React elements, matching the existing
Field.descriptionAPI.Why?
Form card descriptions were limited to strings, preventing them from including links or other rich content.
How?
Updates the form field types, verifies React elements survive normalization, and demonstrates a linked description in Storybook. The story uses static source generation to avoid a Storybook-only serialization limitation.
Testing Instructions
npm run storybook:dev.npm run test:unit -- packages/dataviews/src/components/dataform-layouts/test/normalize-form.ts --runInBandTesting Instructions for Keyboard
Tab to the “customer information guide” link and confirm it receives focus and can be activated with Enter.
Screenshots or screencast
Not included; the behavior is demonstrated in Storybook.
Use of AI Tools
OpenAI Codex was used to investigate and implement the change, update tests and Storybook, and draft this description.