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

Migrate store/actions from editor package to fields package #65289

Merged
merged 26 commits into from
Sep 25, 2024

Conversation

gigitux
Copy link
Contributor

@gigitux gigitux commented Sep 12, 2024

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:

  • deletePostWithNotices
  • editPostWithNotices

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:

const { removeTemplates } = unlock(
useDispatch( editorStore as StoreDescriptor )
);

duplicateTemplatePart

The blocker for this action is CreateTemplatePartModalContents:

<CreateTemplatePartModalContents
blocks={ blocks }

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:

const { revertTemplate } = unlock(
useDispatch( editorStore as StoreDescriptor )
);


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.

  1. Visit the Site Editor.
  2. Visit the patterns view.
  3. Smoke test all the actions available.
  4. Visit the templates view.
  5. Smoke test all the actions available.
  6. Visit the page view.
  7. Smoke test all the actions available.

Testing Instructions for Keyboard

Screenshots or screencast

@youknowriad
Copy link
Contributor

I'm wondering how we should tackle this. Should we re-implement removeTemplates in @wordpress/fields? 🤔

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.

Copy link
Contributor Author

@gigitux gigitux Sep 13, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@gigitux
Copy link
Contributor Author

gigitux commented Sep 16, 2024

cc @youknowriad @oandregal I'm marking this PR ready for review!

@gigitux gigitux marked this pull request as ready for review September 16, 2024 09:14
Copy link

github-actions bot commented Sep 16, 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 <gigitux@git.wordpress.org>
Co-authored-by: louwie17 <louwie17@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Copy link
Contributor

@louwie17 louwie17 left a 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';
Copy link
Contributor

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

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

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, {
Copy link
Contributor

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.

Copy link
Contributor Author

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 } ) => {
Copy link
Contributor

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

Copy link
Contributor Author

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should move this up.

@gigitux
Copy link
Contributor Author

gigitux commented Sep 18, 2024

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.

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

@@ -0,0 +1,2 @@
declare module '@wordpress/editor';
declare module '@wordpress/patterns';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this about?

Copy link
Contributor

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

Copy link
Contributor Author

@gigitux gigitux Sep 18, 2024

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

@youknowriad youknowriad added [Type] Code Quality Issues or PRs that relate to code quality [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Sep 18, 2024
},
};

export default deletePostAction;
Copy link
Contributor

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?

Copy link
Contributor Author

@gigitux gigitux Sep 18, 2024

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

@oandregal
Copy link
Member

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 @@
/**
Copy link
Member

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?

Copy link
Contributor Author

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”

Copy link
Member

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?

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

Copy link
Member

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 the NoticeSettings type) is just used by the delete-post action. Can we inline it in that file instead?

Copy link
Contributor Author

@gigitux gigitux Sep 25, 2024

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:

Instead editPostWithNotices could be used with:

@gigitux
Copy link
Contributor Author

gigitux commented Sep 25, 2024

What's the status of this PR? It has an approval, can it be merged, do you need help with that @gigitux ?

I can't merge it! I was thinking that more feedback was necessary before the merge! On my side, would be great if you merge it, so I can unblock #65390

@oandregal
Copy link
Member

oandregal commented Sep 25, 2024

I can't merge it! I was thinking that more feedback was necessary before the merge! On my side, would be great if you merge it, so I can unblock #65390

Oh, I see. I will merge then to unblock further work. We can still iterate on this all.

@oandregal oandregal merged commit cb44f51 into WordPress:trunk Sep 25, 2024
64 checks passed
@oandregal oandregal changed the title [Fields] Migrate store and actions from editor package to fields package #2 Continue migrating store/actions from editor package to fields package Sep 25, 2024
@github-actions github-actions bot added this to the Gutenberg 19.4 milestone Sep 25, 2024
@oandregal
Copy link
Member

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 [ XXXX ] YYY in favor of a more descriptive name, when possible.

@oandregal oandregal changed the title Continue migrating store/actions from editor package to fields package Migrate store/actions from editor package to fields package Sep 25, 2024
@gigitux
Copy link
Contributor Author

gigitux commented Sep 25, 2024

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 [ XXXX ] YYY in favor of a more descriptive name, when possible.

Thanks for sharing it! 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants