Register view/form config in the server #76544

Part of

• DataViews and DataForm: Extensibility #61084
• DataViews, DataForm, et al. in WordPress 7.1 #76045

Backported at WordPress/wordpress-develop#11272

What

We want to introduce the ability to configure the view/form config received by DataViews/DataForm for any given entity. For example, 3rd parties should be able to change what fields are visible in DataViews, or the default layouts.

How

• Retrieve the view/form config for a given entity from a new REST endpoint.
  • Site Editor > Pages: move view config to the server #76573
  • Site Editor > Quick Edit: add form config to endpoint #76953
  • Site Editor > Pages > QuickEdit (consider bulk editing)
  • Site Editor > Identity. Should we allow extending that form?
  • Editor > DataForm Inspector (experiment)
  • Site Editor > Templates: move config to the server #76622
  • Site Editor > Templates (with template experiment enabled)
  • Site Editor: simplify sidebar for Pages & Templates #76868
  • Site Editor > Patterns: move config to the server #76734
  • Site Editor > Patterns & Parts: generate sidebar from view config #76823
  • Migrate experiment "site editor extensibility" for Pages, Templates, Patterns.
  • Naming: is "view config" the best name? It also has form config, for example (related).
  • Endpoint should allow filtering fields (e.g., only respond with form but no default_view or view_list so that we always send the minimal data).
• API for registration & filtering
  • Extract entity view config into a filterable API #78977
  • Identifier. How do we support screens that don't match 1:1 to entities (e.g., Connectors, Settings?). (Related conversation)
  • Consider versioning. If the view changes, the existing filters should still work. View Config: Add version handling wordpress-develop#12391
• Custom layouts
  • Explore custom layouts (needs to bundle TSX/CSS). It's related to supporting custom layouts in DataViews/DataForm and the mechanism to load bundles for fields as well.
• Data
  • View list: icons and counts are not part of the endpoint
    • Sidebars for all pages have icons as part of the view list (e.g., icon for "Published pages" is different than icon for "Draft pages"). Check if we need icons for the view list provided by any entity when this project progresses a bit more. Related.
    • The Patterns&Parts screen displays the number of items per category — it's the only one. Related.
    • There's an ongoing experiment that redesigns the site editor which doesn't use icons or counts for the view lists, so we've decided against adding them to the endpoint for now. We can revisit later, when we have more information.
  • default_layouts: can each of the view list have different default layouts? Right now, it's for all the entity.