-
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
Migrate store/actions from editor package to fields package #65289
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.
packages/fields/README.md
Outdated
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. |
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:
editPostWithNotices
is not used anywhere. Can we removed it?deletePostWithNotices
(and theNoticeSettings
type) is just used by thedelete-post
action. 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
mutation
folder: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
This PR is a follow-up of #65261. With this PR, all actions have been migrated except for:
deletePostAction
The blocker for this action is the dispatch of
removeTemplates
action imported by the@wordpress/editor
package:gutenberg/packages/editor/src/dataviews/actions/delete-post.tsx
Lines 53 to 55 in 4356a42
duplicateTemplatePart
The 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/editor
package by another component.resetPost
The blocker for this action is the dispatch of
removeTemplates
action imported by the@wordpress/editor
package: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
removeTemplates
in @wordpress/fields? 🤔cc @youknowriad @oandregal
Testing Instructions
Ensure that
Custom Dataviews
is enabled.Testing Instructions for Keyboard
Screenshots or screencast