DataForm: render untyped fields without an edit control that are read-only

[dmallory42]

What?

Render read-only DataForm fields that have no edit control.

Why?

A field with readOnly: true and a custom render disappears unless it also defines Edit or a type that supplies one. Information-only fields should be able to use their display renderer without declaring an unused input control.

How?

Only require Edit for editable fields in the regular layout. Keep editable fields without a control hidden, and check the optional control before rendering it.

Add regression coverage for top, side and hidden labels. All three read-only cases fail before the fix and pass afterwards. This changes no field API or saving behaviour.

Testing Instructions

1. Render a DataForm with this field definition and form.fields: [ 'status' ]:

   {
       id: 'status',
       label: 'Account status',
       readOnly: true,
       render: () => <span>Account connected</span>,
   }

2. Confirm the text appears without adding type or Edit.

3. Set form.layout to { type: 'regular', labelPosition: 'side' }, then repeat with 'top' and 'none'. Confirm the value appears in every layout and the label is omitted for 'none'.

4. Remove readOnly and confirm the field is hidden because it has no edit control.

Validation completed:

• All 36 tests in packages/dataviews/src/dataform/test/dataform.jsdom.test.tsx pass.
• npm run typecheck -- packages/dataviews, lint on the changed TypeScript files and npm run build pass.
• Verified all three label layouts in a local browser harness using the built DataForm package.

Testing Instructions for Keyboard

Tab through a form containing editable fields and the read-only field above. The read-only text should remain visible without adding an input or a tab stop.

Screenshots or screencast

Use of AI Tools

Codex investigated the rendering guard, implemented the fix and regression tests, ran validation, and drafted this PR. This draft is awaiting human review.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. To trigger a review, include @coderabbitai review in the PR description. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: d19a9760-a6d6-4c52-8da0-2bca74047a08

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 PR meta 🤖

👋 Welcome

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dmallory42! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[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: dmallory42 <dmallory42@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>

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

[oandregal]

I'm pushing some examples for the stories:

• regular

• panel

• details

• card

• row

[ntsekouras]

Don't we need similar handling for the card layout?

[oandregal]

The panel layout already covers for read-only fields (code) by only rendering the summary button. Any other layout (details, card, row) delegates to either regular or panel so they are not impacted.

[ntsekouras]

I think the issue is valid since a read-only field rendered as its own card (no children) still returns null. The payments field in the card story is exactly that case and it only shows up because of its type: 'text'. If you remove the type, the card disappears.

[oandregal]

Ah, interesting, good catch.

So the card is the only layout that, before delegating rendering, decides on its own whether a single field should render at all (to prevent empty cards). I understand changing this would be too complex (a portal so the children can control the parent's render), so my recommendation would be to create a shared util so it's obvious that this logic should be connected.

[dmallory42]

Thanks André and Nik. I’ve pushed a shared helper for the regular and single-field card layouts, with tests for the read-only case and for avoiding an empty card when there’s no edit control. I also adjusted the Payments story to cover the single-field case. Does this look like the approach you had in mind?

Could you also add the [Type] Bug label, please? I don’t have permission to add it.

[oandregal]

@dmallory42 the issue here is that the field doesn't provide a type or a Edit, so the framework doesn't know how to display it.

The field type is not required yet because we started without it, but it's a strong recommendation. We aim to make it required. Was it intentional that the field didn't have a type? Would it be an issue to add one?

[oandregal]

I don't mind adding this for the case of untyped fields with no custom Edit, though the recommendation is to add a type (see).

[oandregal]

@dmallory42 I leave the approval but #82514 (comment) needs fixing.

[dmallory42]

Thanks André, that makes sense. We’ll keep type: 'text' for our text information fields in WooCommerce. We originally omitted it because we supplied a custom renderer and didn’t need an edit control. I’d propose keeping this fix for untyped read-only fields while the API still allows them. Does that sound reasonable?