Related:

• Admin redesign: Settings #63624
• Data views: quick-editing #55101
• DataViews component #55083

Problem scope

As we continue expanding our UIs, be it the editor UI or new pages being added to the site editor, we’re finding our selves creating a lot of forms to edit entities and for each one of these, we keep recreating adhoc designs and implement adhoc forms.

Here are some of the existing forms:

Where	Screenshot
The inspector panel for post/pages/templates/patterns
Forms to create new patterns/pages/templates
Details panels

Also, as we advance into the admin redesign work, we’ll be creating even more forms:

• creating and editing media (media quick edit) for the Media Library project
• creating and updating categories
• quick edit for the dataviews
• bulk editing for the dataviews

To avoid creating and designing UIs for these over and over again in an ad-hoc and inconsistent way, we should explore an API to generate these forms consistently.

Proposal

When implementing the DataViews in the site editor, we introduce a “fields” config for each data view component. To render a DataView, we’ve built a generic component with the following API:

<DataViews data={data} fields={ fields } view={ view } />

So this component render a list of items given a “fields” config and a some options (view).

Similarly, we should explore building a generic component that renders a form/panel

<DataForm item={item} fields={ fields } form={ form } />

Such component would render a form or panel for a given item based on a “fields” config and some options (form).

Notes

• It would be good to share the same “fields” config as the one used in the dataviews project, I think this might force us to formalize the field “types” more.
• Having a reusable component like that will also allow us to provide a consistent extensibility API ultimately.
• A library like that could be a good inspiration https://github.com/pmndrs/leva
• Let’s try to explore this as a prototype, for instance let’s have an initial goal of building a quick edit form for posts (basically recreate the inspector panel for posts) and try to discover what kind of config we need there.

Tasks

• DataForm: implement first prototype using duplicate page action #63032
• DataViews: Bootstrap Quick Edit #63600
• DataForm: Add a simple story for the DataForm component #63840
• DataForm: migrate order action modal and introduce form validation #63895
• DataForm: add author to quick edit page/post list #63983
• DataForm: move validation logic to the field type definition #64164
• DataViews: formalize text field type definition #64168
• DataForm: replicate DocumentInspector in QuickEdit #64519
• DataForm: make it work nicely with bulk editing #65685
• Data Views: Implement selectItem callback #66338
• Layout flexibility Move DataForm layout to the field level #66531
• Extensibility API - Assess how a plugin can register its field (or field type) using dedicated APIs.
• Sync edits
  • When user edit the title in the editor and then visit Pages, both the DataViews and QuickEdit should have the new title.
  • When users edit the title via QuickEdit, DataViews should reflect the new title immediately. If the users visit the Editor at that point, they should also see the new title.

Improvements

• DataForm: Consolidate render function argument #66616
• DataForm: Improve loading state management #66599
• Data Form: define props to differentiate field layouts #66336

Fields improvements

• Featured Image Field: Improve layout #66332
• Implement validation to the Slug field QuickEdit: Add slug field control #65196 (comment)