-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Migrate store/actions from editor package to fields package #65289
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
Conversation
Yes, It can either be moved to the "component" itself or move to core-data. I might prefer in the component directly for now like all the other actions. |
4db6b4c to
63adf35
Compare
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 action has been renamed into reset-template.
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.
These fields are already available in @wordpress/fields 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.
In a dedicated PR, I will improve documentation.
b34c830 to
39d25d1
Compare
|
cc @youknowriad @oandregal I'm marking this PR ready for review! |
|
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. |
louwie17
left a comment
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.
Overall looks good @gigitux and it tested well. I did notice several places where you still had some @wordpress/* imports under the Internal Dependencies comment block. I am not sure why the linter didn't catch this, maybe that is missing in the fields package still?
I left a couple other thoughts, but those aren't blockers.
| } from '../utils'; | ||
| import type { CoreDataError, Template, TemplatePart } from '../../types'; | ||
| import { addQueryArgs } from '@wordpress/url'; | ||
| import apiFetch from '@wordpress/api-fetch'; |
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.
These two should be moved up to WordPress dependencies
| */ | ||
| import { isTemplateRemovable, getItemTitle } from '../utils'; | ||
| import type { Template, TemplatePart } from '../../types'; | ||
| import { decodeEntities } from '@wordpress/html-entities'; |
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 should be moved to to WordPress dependencies
| */ | ||
| import { getItemTitle } from '../utils'; | ||
| import type { Pattern } from '../../types'; | ||
| import { decodeEntities } from '@wordpress/html-entities'; |
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 should be moved up to WordPress dependencies
| const onConfirm = async () => { | ||
| try { | ||
| for ( const template of items ) { | ||
| await revertTemplate( template, { |
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.
Having to copy this from the core/edit-site data store makes me wonder if this is something that should be passed in as a config. A onResetTemplate function that is optional, but can be passed into the action?
Could of-course be a follow up.
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.
Having to copy this from the core/edit-site data store makes me wonder if this is something that should be passed in as a config
From what I understood, it looks like all actions that manipulate WordPress entities should exist in the @wordpress/core-data package.
Given that this PR is already big, and we are still evaluating multiple ideas, I followed the @youknowriad suggestion's to move it into this package.
| }, | ||
| supportsBulk: true, | ||
| hideModalHeader: true, | ||
| RenderModal: ( { items, closeModal, onActionPerformed } ) => { |
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.
Could the RenderModal for this one and delete-template be shared?
I realize currently this doesn't have access to the above action, but maybe we can move this into a thin wrapper?
A future idea is to pass the action into the RenderModal https://github.com/WordPress/gutenberg/blob/trunk/packages/dataviews/src/components/dataviews-item-actions/index.tsx#L115
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.
Could the RenderModal for this one and delete-template be shared?
Good point! I would keep them separate and if we will see an overlap with other entities try to create a shared modal.
| * Internal dependencies | ||
| */ | ||
| import type { CoreDataError, Post } from '../types'; | ||
| import { dispatch } from '@wordpress/data'; |
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 move this up.
Fixed with 485237f! It is a nice catch, btw! I noticed that other packages suffer the same issue. I'm going to do a quick investigation and open an issue! EDIT: I opened the issue: #65440 |
packages/fields/src/module.d.ts
Outdated
| @@ -0,0 +1,2 @@ | |||
| declare module '@wordpress/editor'; | |||
| declare module '@wordpress/patterns'; | |||
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.
What is this about?
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.
Why didn't we need something like it before (when the actions were in editor).
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.
Because we are using @ts-ignore to ignore the errors. Both solutions aren't great and given that we are already using @ts-ignore, let's remove this file - 0deeed3
| }, | ||
| }; | ||
|
|
||
| export default deletePostAction; |
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'm assuming there's no change in logic in the two actions that Github didn't caught as files being moved right?
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.
No, I didn't change the logic! Thanks for the review! 🙇
|
What's the status of this PR? It has an approval, can it be merged, do you need help with that @gigitux ? |
| @@ -0,0 +1,184 @@ | |||
| /** | |||
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.
Why these actions are not top-level like any other?
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.
The idea is that these functions are utils and not “proper actions”
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.
Why is the folder called mutation and not utils?
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 a dedicated folder to highlight that these utils “mutate” an entity. I don't have a strong preference, I'm happy to put this file at top level and rename it to utils.ts
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.
Looking at the code:
editPostWithNoticesis not used anywhere. Can we removed it?deletePostWithNotices(and theNoticeSettingstype) is just used by thedelete-postaction. Can we inline it in that file instead?
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.
True! To not make this PR too big, I didn't "migrate" existent actions to these two utils, but deletePostWithNotices could be used:
permanently-delete-post:
const permanentlyDeletePost: Action< PostWithPermissions > = { trash-post:
const restorePost: Action< PostWithPermissions > = {
Instead editPostWithNotices could be used with:
restore-post:
const restorePost: Action< PostWithPermissions > = { reset-post:
const resetPostAction: Action< Template | TemplatePart > = {
Oh, I see. I will merge then to unblock further work. We can still iterate on this all. |
|
btw, there's some automation to generate the changelog for each Gutenberg (plugin) release. One thing we do is to take the PR names to generate the changelog, for example: https://make.wordpress.org/core/2024/09/12/what-is-new-in-gutenberg-19-2-11-september/ The better names they have, the less work the release coordinator has to do :) I'd suggest would be avoiding formats like |
Thanks for sharing it! 🙇 |
What?
This PR continues the work started in PR #65261 by migrating the remaining actions, with the exception of
DuplicateTemplatePart, which will be addressed in a separate PR.Changes Introduced
To avoid code duplication and standardize the way actions are written in the codebase, this PR introduces two new functions in the
mutationfolder:Happy to revisit the naming of these functions!
These functions handle the updating of entities and manage success and error notices. The logic they encapsulate was previously duplicated across multiple actions, so unifying it into these functions should improve maintainability.
Currently, there are other entities in this package that update entities without using these two utils. I'm going to refactor them once this PR is merged.
Old description
Details
This PR is a follow-up of #65261. With this PR, all actions have been migrated except for:
deletePostActionThe blocker for this action is the dispatch of
removeTemplatesaction imported by the@wordpress/editorpackage:gutenberg/packages/editor/src/dataviews/actions/delete-post.tsx
Lines 53 to 55 in 4356a42
duplicateTemplatePartThe blocker for this action is
CreateTemplatePartModalContents:gutenberg/packages/editor/src/dataviews/actions/duplicate-template-part.tsx
Lines 53 to 54 in 4356a42
This component is used in the
@wordpress/editorpackage by another component.resetPostThe blocker for this action is the dispatch of
removeTemplatesaction imported by the@wordpress/editorpackage:gutenberg/packages/editor/src/dataviews/actions/reset-post.tsx
Lines 44 to 46 in 4356a42
I'm wondering how we should tackle this. Should we re-implement
removeTemplatesin @wordpress/fields? 🤔cc @youknowriad @oandregal
Testing Instructions
Ensure that
Custom Dataviewsis enabled.Testing Instructions for Keyboard
Screenshots or screencast