DataViews: Extensibility

[youknowriad]

Part of https://github.com/WordPress/gutenberg/issues/55083

What problem does this address?

As we grow the usage of the DataViews package in the different editors. The need for extensibility for the different configuration objects grows. The dataviews package is built in a way that allows extensibility to be implemented in multiple places and open a new wave of possibility for plugins and third-party developers:

We should be able to:

• Register fields which would make them available for users to render in any layout (table, grid, list or custom) per post type. (Registering fields, also means registering filters)
• Define the default fields per post type. (User modifications prevail)
• Register/unregister actions and bulk actions per post type.
• Register custom layouts for data-views: for instance being able to add a custom "timeline" layout or a "calendar" layout to render the dataviews in a different layout.

What others would you like to see being extensible in the dataviews? Let's gather some thoughts.

Note

A lot of the above features are still very much in flux and the structure of these objects will probably change (breaking changes) while we iterate there. In the meantime, it is important to get third-party feedback to shape these objects and extensibility APIs properly. And given the scale of these APIs, we should start implementing these APIs as Gutenberg plugin-only APIs, gather real usage feedback on the plugin before committing to shipping these APIs into Core. (Use the IS_GUTENBERG_PLUGIN as a start).

Todo

Common

• [ ] Versioning the APIs #67274

Actions

• [x] Bootrasp the extensibility API to add/remove actions. #62052
• [x] Figure out a way to use the registry and stores in globally registered actions (Related discussion here ). This will unblock the next todo item here.
• [x] Moving all the existing post actions to globally registered actions and typed actions in packages/editor/src/dataviews/actions (there are three examples there already). This will allow third-party developers to unregister these actions if needed.
• [ ] Audit the action "ids" and bring some consistency there.
• [ ] Audit the action code bases and improve things like notices and error handling (most of these can be absorbed into the framework I think)
• [x] Consider moving editor/src/dataviews to a dedicated package: core-entities-fields or core-entities or something like that. core-data can also be considered a good place for that.
• [ ] Add validation to the registration functions.
• [ ] Add a documentation page to the handbook (clarify that it's experimental).

Fields

• [ ] Pull all fields in post-edit and post-list from the registry.
  • [x] https://github.com/WordPress/gutenberg/pull/66939
  • [x] https://github.com/WordPress/gutenberg/pull/66938
  • [x] https://github.com/WordPress/gutenberg/pull/66940
  • [x] https://github.com/WordPress/gutenberg/pull/66934
  • [x] https://github.com/WordPress/gutenberg/pull/66937
  • [x] https://github.com/WordPress/gutenberg/pull/67024
  • [x] https://github.com/WordPress/gutenberg/pull/67175
  • [ ] Implement the formats field and display different fields for post and page post types. See https://github.com/WordPress/gutenberg/pull/67175#discussion_r1852089343
• [ ] Make all fields in page-patterns come from the registry.
• [ ] Make all fields in page-patterns come from the registry.

[fabiankaegy]

Thanks for opening this issue :)

I want to reference back to this comment / thread in the original "Expanding the Table component" issue from a year ago:

https://github.com/WordPress/gutenberg/issues/53233#issuecomment-1665263796

[oandregal]

Related ticket about (duplicate post) actions extensibility https://github.com/WordPress/gutenberg/issues/61083 considering user capabilities, ability to filter by plugins, etc.

[youknowriad]

I've started thinking about this a little bit (focusing on actions first). So we want to be able to define actions per post type and the first question I had to answer is where should the API live? In which package?

• It can't live in the DataViews package since it's a generic package.
• It can't live in the site editor package ultimately, since it's DataViews are probably going to be outgrow that package and be used in different packages.
• They are very tied to post types, so potentially core-data could be a good package.
• Right now the actions are defined in the editor package so it could also be a good starting point for that.
• Ultimately though, I feel like a dedicated package for post types dataviews, where we define default fields, default actions for all the post types and allow extensibility would be a better fit.

I'm thinking of starting exploring the "editor" package first and we can adapt over time. WDYT.

[youknowriad]

I updated the issue with some tasks that can be grabbed. Let's keep it up to date as we iterate and clarify what needs to be done.

[youknowriad]

Hello folks, Small update here.

• I've moved and typed a couple post type actions to globally registered actions which allows third-party developers to unregister them if they choose to.
• There's a technical blocker to move the rest of the actions though (details in the todo list of the issue)

I'm going to pause or slow down the work on the issue to focus on other priorities I have at the moment. But if folks are interested to continue push this forward, the todo list should help and I'm happy to provide support. cc @Mamaduka @jsnajdr @fabiankaegy

[talldan]

Not sure if this is the right place to mention it, but I found this old issue, which seems relevant for data views for post types - Post actions: "force delete" isn't supported

Testing today and the post editor shows ‘Move to trash’ as an action, but the post isn’t deleted when clicking it.

[oandregal]

Over the past week, I've been moving some things around (field definitions to the fields package, usePostFields hook to the editor package) in preparation for this PR https://github.com/WordPress/gutenberg/pull/67175 It allows register/unregister fields for the page post type, in the same way we do with actions.

Updated the issue description with all this info. The conditions for this to work are the same as actions: it only works with the Gutenberg plugin active and it's private.

[youknowriad]

Before being able to stabilize the APIs, we need to implement apiVersion for all these configs. I created this issue to track this work #67274