-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
DataViews: allow register/unregister fields #67175
Changes from 4 commits
3012632
7443615
8649f93
df078fd
3e6782e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ | |
* WordPress dependencies | ||
*/ | ||
import { store as coreStore } from '@wordpress/core-data'; | ||
import type { Action } from '@wordpress/dataviews'; | ||
import type { Action, Field } from '@wordpress/dataviews'; | ||
import { doAction } from '@wordpress/hooks'; | ||
|
||
/** | ||
|
@@ -24,6 +24,15 @@ import { | |
renamePost, | ||
resetPost, | ||
deletePost, | ||
featuredImageField, | ||
dateField, | ||
parentField, | ||
passwordField, | ||
commentStatusField, | ||
slugField, | ||
statusField, | ||
authorField, | ||
titleField, | ||
} from '@wordpress/fields'; | ||
import duplicateTemplatePart from '../actions/duplicate-template-part'; | ||
|
||
|
@@ -53,11 +62,38 @@ export function unregisterEntityAction( | |
}; | ||
} | ||
|
||
export function setIsReady( kind: string, name: string ) { | ||
export function registerEntityField< Item >( | ||
kind: string, | ||
name: string, | ||
config: Field< Item > | ||
) { | ||
return { | ||
type: 'REGISTER_ENTITY_FIELD' as const, | ||
kind, | ||
name, | ||
config, | ||
}; | ||
} | ||
|
||
export function unregisterEntityField( | ||
kind: string, | ||
name: string, | ||
fieldId: string | ||
) { | ||
return { | ||
type: 'UNREGISTER_ENTITY_FIELD' as const, | ||
kind, | ||
name, | ||
fieldId, | ||
}; | ||
} | ||
|
||
export function setIsReady( kind: string, name: string, part: string ) { | ||
return { | ||
type: 'SET_IS_READY' as const, | ||
kind, | ||
name, | ||
part, | ||
}; | ||
} | ||
|
||
|
@@ -66,15 +102,17 @@ export const registerPostTypeActions = | |
async ( { registry }: { registry: any } ) => { | ||
const isReady = unlock( registry.select( editorStore ) ).isEntityReady( | ||
'postType', | ||
postType | ||
postType, | ||
'actions' | ||
); | ||
if ( isReady ) { | ||
return; | ||
} | ||
|
||
unlock( registry.dispatch( editorStore ) ).setIsReady( | ||
'postType', | ||
postType | ||
postType, | ||
'actions' | ||
); | ||
|
||
const postTypeConfig = ( await registry | ||
|
@@ -139,3 +177,46 @@ export const registerPostTypeActions = | |
|
||
doAction( 'core.registerPostTypeActions', postType ); | ||
}; | ||
|
||
export const registerPostTypeFields = | ||
( postType: string ) => | ||
async ( { registry }: { registry: any } ) => { | ||
const isReady = unlock( registry.select( editorStore ) ).isEntityReady( | ||
'postType', | ||
postType, | ||
'fields' | ||
); | ||
if ( isReady ) { | ||
return; | ||
} | ||
|
||
unlock( registry.dispatch( editorStore ) ).setIsReady( | ||
'postType', | ||
postType, | ||
'fields' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we avoid this argument and just have a global registration function for entities that register both actions and fields? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Renamed |
||
); | ||
|
||
const fields = [ | ||
featuredImageField, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't we need the post type config to add some fields conditionally? For example featured image is the post type supports it, etc.. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've tracked this follow-up in the overview issue #61084 |
||
titleField, | ||
authorField, | ||
statusField, | ||
dateField, | ||
slugField, | ||
parentField, | ||
commentStatusField, | ||
passwordField, | ||
]; | ||
|
||
registry.batch( () => { | ||
fields.forEach( ( field ) => { | ||
unlock( registry.dispatch( editorStore ) ).registerEntityField( | ||
'postType', | ||
postType, | ||
field | ||
); | ||
} ); | ||
} ); | ||
|
||
doAction( 'core.registerPostTypeFields', postType ); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have two post types that work with the same fields: the
Pages
page pulls data for thepage
post type, and the experimental post screen (enable in "Gutenberg > Experiments > Redesigned post dashboard") does the same with posts.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While they have the same fields in dataviews, this is how we display them in the post editor:
It sounds a follow-up to this PR should be implementing the format field for the
post
post type, and add thepostType
parameter to theusePostFields
hook.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This conversation is relevant: plan is to move them to
@wordpress/fields
package when it becomes stable.