-
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
Move duplicateTemplatePart
action to the @wordpress/fields
package
#65390
base: trunk
Are you sure you want to change the base?
Conversation
@@ -152,10 +208,14 @@ export function CreateTemplatePartModalContents( { | |||
label={ __( 'Area' ) } | |||
className="editor-create-template-part-modal__area-radio-group" |
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.
Should I update these classes even if it is a temporary solution?
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.
Yeah I think we should update them ideally fields
instead of editor
basically.
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 updated it with 199c313
… into add/action-dataviews-3
@oandregal I rebased this PR after #65289 has been merged. Let me know if you agree with the current method, or if you believe a dedicated package should be created for these template-related components. P.S: As reminder, we are in cooldown, so I'm not strictly focused on this project. I may be slow (I will do my best) on checking your feedback 🙇 |
I rebased this PR and it is ready to be reviewed. My main concern is this one:
|
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. |
@@ -13,7 +13,7 @@ import { symbolFilled } from '@wordpress/icons'; | |||
/** | |||
* Internal dependencies | |||
*/ | |||
import CreateTemplatePartModal from '../create-template-part-modal'; | |||
import { CreateTemplatePartModal } from '@wordpress/fields'; |
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.
Yes, I agree this is weird, but also not sure what's the best place for these wp-core-data aware components. That said I can live with it being in fields for now.
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.
Maybe we should add a comment explaining the choice.
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.
With 47da440 I added some documentation.
packages/fields/src/constants.ts
Outdated
plugin: 'plugin', | ||
}; | ||
|
||
export const TEMPLATE_PART_AREA_DEFAULT_CATEGORY = 'uncategorized'; |
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.
Personally I hate these constants file and would rather mostly remove them (especially since most of these types are "typed" now.
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.
Removed with 64423cf
[] | ||
); | ||
|
||
const defaultTemplatePartAreas = getDefaultTemplatePartAreas( settings ); |
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.
Personally, I think this is the wrong solution to retrieving the default template areas. There might not be a rendered block-editor when using the fields, so I don't think a dependency to "block-editor" is the right approach.
The main issue here is that defaultTemplateTypes
and defaultTemplatePartAreas
are passed from the server to the client through the editor settings initialization. I think this is the wrong approach. The right approach would be to move these to getEntityRecord( 'root', '__unstableBase' )
endpoint and add them in the server to this endpoint. I believe we did things like that in the past for things like site_icon_url
... Do you think this is something we can try in its own PR. I'm a bit concerned that the current field won't work as expected in all contexts.
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.
Do you think this is something we can try in its own PR. I'm a bit concerned that the current field won't work as expected in all contexts.
I'm happy to work on it with a dedicated PR! 💪
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 created #66459. Let me know if you agree with the approach that I took!
Warning
This branch of this PR is based on #65289.
What?
This PR migrates the
duplicateTemplatePart
action to the@wordpress/fields
package. The primary issue with this action is its dependency on theCreateTemplatePartModalContents
component, which resides in the@wordpress/editor
package. Due to this, it can't be directly used within the@wordpress/fields
package.For the purpose of the
@wordpress/fields
package work, I have temporarily moved the component to this package. However, I'm not certain if this is the best long-term solution. Ideally, this component (and potentially others) should reside in a dedicated package, such as@wordpress/template
, which would be more appropriate for components related to template and template-parts. A similar package for the patterns already exists: https://github.com/WordPress/gutenberg/blob/d6fcf4aea4aff17cf0910862bf10090e20ba2ab0/packages/patterns/srcPlease review and provide feedback on whether this approach is suitable or if there are alternative recommendations for handling these dependencies. Thanks! 🙏 cc @youknowriad @oandregal
Testing Instructions
Ensure that
Custom Dataviews
is enabled.Testing Instructions for Keyboard
Screenshots or screencast