Block Fields: fully adopt the DataForms API

[ramonjd]

Follow up to:

• ContentOnly Patterns experiment: Add content only inspector fields #71730

Issue Summary

Goal: Migrate editable fields from PR #71730 to use the DataForms API instead of recreating similar functionality.

Key Points

Context

• PR ContentOnly Patterns experiment: Add content only inspector fields #71730 introduces editable fields in block settings, but the implementation largely recreates DataForm behavior
• Current approach is guarded behind an experiment, allowing for iteration

Proposed Approach

✅ Phase 1: Investigation (Time-boxed)

Started in #73180

• Validate whether DataForm can support the UI/UX requirements from ContentOnly Patterns experiment: Add content only inspector fields #71730
• Identify compatibility gaps and blockers
• Determine which components need to be hard-coded vs. generic

Phase 2: Migration

• Consider replacing ToolsPanel with simpler heading + DropdownMenu for visibility controls
• Replace custom implementation with DataForm components
• Align settings.fields shape with DataForm API conventions
  • Use type to correspond with DataForm controls
  • Use id instead of custom mappings where possible
  • Remove shownByDefault for controlling which fields are visible (possibly look at isVisible). WIP PR in Content only block experiment: blocks provide the form #73479
  • Each field's Edit function should not update the blocks directly. It should just emit a new value, with the block updates happening in the DataForm's onChange callback (see comment on: ContentOnlyControls: Refactor to use DataForm #73374 (comment))
  • mapping support should be added to the Field API, possibly through a properties key, that provides the mapping. Content-only: remove mapping and args in favor of DataForm API #74575
  • Remove args and instead use Edit config instead (also see comment: ContentOnlyControls: Refactor to use DataForm #73374 (comment))

Missing DataForm Controls to Address (so far)

• RichText control see DataForm: Add a generalised richtext field #73180
• Media/MediaItem control see Fields: Replace the FeaturedImageEdit field to a more general MediaUpload field #72614 (with square/round-rect thumbnail, similar to Site Logo. Show image preview instead of icon. See ContentOnly Patterns experiment: Add content only inspector fields #71730 (comment) )
• Link control

Note: These could use ad hoc Edit components initially, but should be added to DataForm proper

Additional Considerations

• Explore field visibility/filtering mechanism (some fields like image links and captions could be shown by default to reduce long field lists)
• A small wrapper component to manage which fields are displayed is acceptable
• Block Fields: add inspector 'fields' support for blocks like Site Tagline, Site Logo etc. #73420

Related

• ContentOnly Patterns experiment: Add content only inspector fields #71730
• DataForm: Add a generalised richtext field #73180
• Try content only editable content fields with DataForm #73186

[ramonjd]

Relavant comment:

Eventually, these sidebar controls should be a reflection of block attributes + data fields, where we know the shape and type of attributes and what control handles them.

Not something that is deliverable in the short term, just to keep in mind when we integrate DataForms

[andrewserong]

Not something that is deliverable in the short term, just to keep in mind when we integrate DataForms

I think we can probably get there iteratively, which is to say, attempt to create a structure that mirrors DataForms as close as we can, so that we deviate only when needed. Then that should (hopefully) give us a list of tasks of things to implement (i.e in DataForms controls) to bridge the gap?

[talldan]

The Media field was being separately tracked in #72614. I've updated the issue description to mention it.

[talldan]

Show image preview instead of icon

It already shows a preview/thumbnail, so this part might need some clarification.

[ramonjd]

It already shows a preview/thumbnail, so this part might need some clarification.

For me (looking at trunk) it's possible that the root block being tested was a Cover block: