DataViews: allow register/unregister fields #67175
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
oandregal
added
[Type] New API
oandregal
requested review from
gigitux,
louwie17,
mcsf,
ntsekouras and
youknowriad
13 tasks
|
Size Change: +302 B (+0.02%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
oandregal
commented
Nov 20, 2024
| } | ||
|
|
||
| function usePostFields(): UsePostFieldsReturn { | ||
| const postType = 'page'; // TODO: this could be page or post (experimental). |
Member
Author
There was a problem hiding this comment.
We already have two post types that work with the same fields: the Pages page pulls data for the page post type, and the experimental post screen (enable in "Gutenberg > Experiments > Redesigned post dashboard") does the same with posts.
Member
Author
There was a problem hiding this comment.
While they have the same fields in dataviews, this is how we display them in the post editor:
| Pages | Posts |
|---|---|
 |
 |
It sounds a follow-up to this PR should be implementing the format field for the post post type, and add the postType parameter to the usePostFields hook.
Contributor
There was a problem hiding this comment.
I wonder if ultimately these hooks should received kind/name just like the registration function. I think we'll have this use-case pretty quickly when we start working on the tags/categories dataviews.
Member
Author
There was a problem hiding this comment.
So, we'd have:
useFields( 'postType', 'pages' )instead ofusePostFields( 'page' )useFields( 'taxonomy', 'category' )instead ofuseTaxonomyFields( 'category' )
Under the hood and conceptually, fields and actions are already connected to core-data. Making the kind an argument could work.
Contributor
There was a problem hiding this comment.
Given we would also use this for taxonomies would it make sense to move these actions/selectors to the core data store instead? Given this is more entity specific.
Or in general do we expect every place that uses DataViews/DataForms within WordPress to also import the @wordpress/editor package?
Member
Author
There was a problem hiding this comment.
This conversation is relevant: plan is to move them to @wordpress/fields package when it becomes stable.
youknowriad
reviewed
Nov 21, 2024
| unlock( registry.dispatch( editorStore ) ).setIsReady( | ||
| 'postType', | ||
| postType, | ||
| 'fields' |
Contributor
There was a problem hiding this comment.
Should we avoid this argument and just have a global registration function for entities that register both actions and fields?
Member
Author
There was a problem hiding this comment.
Renamed registerPostTypeActions to registerPostTypeSchema and consolidated everything there 3e6782e
youknowriad
reviewed
Nov 21, 2024
Contributor
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
This is looking good so far
ntsekouras
reviewed
Nov 21, 2024
| ); | ||
|
|
||
| const fields = [ | ||
| featuredImageField, |
Contributor
There was a problem hiding this comment.
Don't we need the post type config to add some fields conditionally? For example featured image is the post type supports it, etc..
Member
Author
There was a problem hiding this comment.
Yes! But I don't want to do it in this PR, I'd rather work on small steps that land fast :)
There's a few other things we need to do: for example, somewhere we need to keep a list of post types <=> fields (see related conversation), but also a bit of validation (return early if post type is unknown), etc..
Would that work for you?
Member
Author
There was a problem hiding this comment.
I've tracked this follow-up in the overview issue #61084
Member
Author
|
@ntsekouras @youknowriad would you think this PR needs to do anything else before landing? |
youknowriad
approved these changes
Nov 22, 2024
Contributor
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
Nik has a good point about the post type supports but we can do that later.
bph
added
the
[Feature] Extensibility
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #61084
What?
This PR updates the
usePostFieldshook to take the fields from a central registry. It also implement the low-level APIs to allow register/unregister a field for any post type.This new API is only available in the Gutenberg plugin and it's private for now.
Why?
This follows suit of what we've done for actions. It is part of how we envision making the entities (dataviews) extensible, see #61084
How?
wp.editor.registerEntityFieldandwp.editor.unregisterEntityField. 7443615usePostFieldshook to take fields from the registry. 8649f93isReadystate to acomodateactionsandfields. df078fdAfter feedback:
registerEntitySchemaand have a singleisReadyfor the post type: 3e6782eTesting Instructions
Go to the Pages page and verify that everything works as expected.
Test unregistering a field. After unregistering it, the field won't be available. In the Pages page, open the console and type:
Screen.Recording.2024-11-20.at.18.23.10.mov
Screen.Recording.2024-11-20.at.18.24.40.mov