Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataForm component #59745

Open
7 of 20 tasks
youknowriad opened this issue Mar 11, 2024 · 8 comments
Open
7 of 20 tasks

DataForm component #59745

youknowriad opened this issue Mar 11, 2024 · 8 comments
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond [Type] Experimental Experimental feature or API. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues

Comments

@youknowriad
Copy link
Contributor

youknowriad commented Mar 11, 2024

Related:

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 Screenshot 2024-03-07 at 4 14 51 PM
Forms to create new patterns/pages/templates Screenshot 2024-03-11 at 9 58 55 AM
Details panels Screenshot 2024-03-07 at 4 14 39 PM

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

Improvements

Fields improvements

@youknowriad youknowriad added [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues [Type] Experimental Experimental feature or API. [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Mar 11, 2024
@oandregal oandregal self-assigned this Jul 1, 2024
@joshuatf
Copy link
Contributor

joshuatf commented Jul 1, 2024

@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
Copy link
Contributor Author

@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
Copy link
Contributor

Noting this is closely related to #63624.

@oandregal
Copy link
Member

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

Also: created #63895 that prepares the initial structure for validation.

@oandregal
Copy link
Member

#63983 adds the ability to update the author in the quick edit form.

@oandregal
Copy link
Member

oandregal commented Aug 1, 2024

In #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:

@oandregal
Copy link
Member

oandregal commented Sep 26, 2024

Edited a bit the issue description, including updating the issue title to DataForm component, like we have the DataViews component.

Also added some new tasks:

  • DataForm: make it work nicely with bulk editing #65685
  • 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.

@gigitux
Copy link
Contributor

gigitux commented Oct 31, 2024

Edited a bit the issue description, adding some issues that we opened in the last weeks. I hope that it is fine!

cc @youknowriad @oandregal @louwie17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond [Type] Experimental Experimental feature or API. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
Status: 🏈 Punted to 6.8
Development

No branches or pull requests

5 participants