DataViews: Forms

[youknowriad]

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:

• 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:

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

To avoid, creating and designing UIs for these over and over again in an adhoc 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.

Log

WordPress 6.7

• https://github.com/WordPress/gutenberg/pull/63032
• https://github.com/WordPress/gutenberg/pull/63600
• https://github.com/WordPress/gutenberg/pull/63840
• https://github.com/WordPress/gutenberg/pull/63895
• https://github.com/WordPress/gutenberg/pull/63983
• https://github.com/WordPress/gutenberg/pull/64164
• https://github.com/WordPress/gutenberg/pull/64168

[joshuatf]

@youknowriad @oandregal Out of curiosity, will the DataForm ever allow control over layout within a form (columns, tabs, sections, etc) or would those be comprised of multiple DataForms?

[youknowriad]

@joshuatf My current thinking is that "columns" and "tabs" are something you should be able to control on the form object. It's not clear to me at this point if a single "form type" can absorb everything or if we'd need several "form layouts" or "form types" like we have for data views, but I think we should be able do say, I want to group these fields in a tab...

[jameskoster]

Noting this is closely related to https://github.com/WordPress/gutenberg/issues/63624.

[oandregal]

Added a new section in the issue for "Task/Log".

Also: created https://github.com/WordPress/gutenberg/pull/63895 that prepares the initial structure for validation.

[oandregal]

https://github.com/WordPress/gutenberg/pull/63983 adds the ability to update the author in the quick edit form.

[oandregal]

In https://github.com/WordPress/gutenberg/pull/63983 I ran into some issues with sorting. While working on them we discussed the need to formalize a bit the existing field types. This is the ongoing work:

• https://github.com/WordPress/gutenberg/pull/64064
• https://github.com/WordPress/gutenberg/pull/64164
• https://github.com/WordPress/gutenberg/pull/64168
• https://github.com/WordPress/gutenberg/pull/64171