Skip to content
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

Open
wants to merge 41 commits into
base: trunk
Choose a base branch
from

Conversation

gigitux
Copy link
Contributor

@gigitux gigitux commented Sep 17, 2024

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 the CreateTemplatePartModalContents 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/src

Please 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.

  1. Visit the Site Editor.
  2. Visit the patterns view.
  3. Click on header
  4. Duplicate a header template part.
  5. Ensure that the duplicated template part is created.

Testing Instructions for Keyboard

Screenshots or screencast

@@ -152,10 +208,14 @@ export function CreateTemplatePartModalContents( {
label={ __( 'Area' ) }
className="editor-create-template-part-modal__area-radio-group"
Copy link
Contributor Author

@gigitux gigitux Sep 17, 2024

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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

@oandregal
Copy link
Member

@gigitux what's the status on this one? I saw #65289 has been approved but not merged yet.

@gigitux
Copy link
Contributor Author

gigitux commented Sep 25, 2024

@gigitux what's the status on this one? I saw #65289 has been approved but not merged yet.

@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 🙇

@gigitux
Copy link
Contributor Author

gigitux commented Oct 24, 2024

I rebased this PR and it is ready to be reviewed. My main concern is this one:

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/src

@gigitux gigitux self-assigned this Oct 24, 2024
@gigitux gigitux added [Type] Experimental Experimental feature or API. [Package] DataViews /packages/dataviews labels Oct 24, 2024
@gigitux gigitux marked this pull request as ready for review October 24, 2024 08:04
Copy link

github-actions bot commented Oct 24, 2024

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: gigitux <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: oandregal <[email protected]>

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';
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

plugin: 'plugin',
};

export const TEMPLATE_PART_AREA_DEFAULT_CATEGORY = 'uncategorized';
Copy link
Contributor

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.

Copy link
Contributor Author

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 );
Copy link
Contributor

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.

Copy link
Contributor Author

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! 💪

Copy link
Contributor Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] DataViews /packages/dataviews [Type] Experimental Experimental feature or API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants