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

[Fields] Migrate store and actions from editor package to fields package #65261

Merged
merged 9 commits into from
Sep 12, 2024

Conversation

gigitux
Copy link
Contributor

@gigitux gigitux commented Sep 12, 2024

What?

This PR moves actions and fields to @wordpress/fields.

Based on the different types, I created subfolder to collect all the actions that belong at the same type.

  • base-post: contains all the actions for the BasePost type.
  • common contains all the actions for the Post type (that it is an union type).
  • pattern contains all the actions for the Pattern type.

We should change the name of the files inside these folders, but I'm going to do in a dedicated PR.

@youknowriad suggested not to move the store at least for now in @wordpress/fields package given that stores are singleton and using them in "bundled packages" create a lot of issues.

Old description

According to this feedback, this PR initiates the process of moving the store and certain actions from the @wordpress/editor package to the @wordpress/fields package. To facilitate easier review and iteration, this work will be divided into multiple smaller PRs. This PR is the first in that series.

Question

This PR migrates all actions that do not depend on the @wordpress/editor package. How should we handle the actions that do depend on the @wordpress/editor package?

Some examples:

Wouldn't it be better if @wordpress/fields only exposed the store, allowing actions to be registered based on the post type, while the actual registration occurs on the @wordpress/editor side?

I can imagine that for plugins that define new postType, the registration will happen on their JS code.

WDYT? @youknowriad @oandregal

Why?

How?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

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 deleted code has been migrated to the @wordpress/fields package

Copy link
Contributor Author

@gigitux gigitux Sep 12, 2024

Choose a reason for hiding this comment

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

The commented code has not yet been migrated to the editor package. I will complete the migration in a subsequent pull request.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copied-pasted from packages/editor/src/dataviews/types.ts

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

Choose a reason for hiding this comment

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

This is necessary because @wordpress/editor package isn't a TypeScript package

@youknowriad
Copy link
Contributor

This PR migrates all actions that do not depend on the @wordpress/editor package. How should we handle the actions that do depend on the @wordpress/editor package?

Looking at these actions, they don't really depend on the "editor" package, they just revertTemplate and resetTemplate actions that are basically just functions that are misplaced, these functions don't need the editor package at all.

Wouldn't it be better if @wordpress/fields only exposed the store, allowing actions to be registered based on the post type, while the actual registration occurs on the @wordpress/editor side?

I'm not sure I understand what you're suggestion: field and actions in the "fields" package, the store in the "fields" package but the registration elsewhere?

@@ -14,17 +15,33 @@ export function usePostActions( { postType, onActionPerformed, context } ) {
const { defaultActions } = useSelect(
( select ) => {
const { getEntityActions } = unlock( select( editorStore ) );
const { getEntityActions: getEntityActionsFromFieldsPackage } =
select( fieldsStore );
Copy link
Contributor

Choose a reason for hiding this comment

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

One thing that I just thought about is that "stores" are singletons and using them in "bundled packages" create a lot of issues. For instance if a third-party decides to use the package as well, we'll end up with two stores that don't talk to each other.

This makes me thing that maybe a first step here is to extract the fields and the actions but to leave the store and registration in the "editor" package for now.

@gigitux
Copy link
Contributor Author

gigitux commented Sep 12, 2024

Looking at these actions, they don't really depend on the "editor" package, they just revertTemplate and resetTemplate actions that are basically just functions that are misplaced, these functions don't need the editor package at all.

Oh ok! Gotcha! Also, in the case of the duplicateTemplatePart, we are using CreateTemplatePartModalContents that it is defined in the editor package.

Sorry for not being clear. I'm going to rephrase/improving my suggestion having new context after you comment.

I'm suggesting to (on long term):

  • fields, actions (that don't depend on editor package) and store in the fields package.
  • keep remaining actions in the @wordpress/editor package, registering them via the registerEntityAction function.

This makes me thing that maybe a first step here is to extract the fields and the actions but to leave the store and registration in the "editor" package for now.

👍 It makes sense! I will update the PR!

@youknowriad
Copy link
Contributor

fields, actions (that don't depend on editor package) and store in the fields package.

I don't think there should be fields in Gutenberg that depend on "editor". It's probably just because they were developed there... The CreateTemplate modal can be moved to the "fields" package.

duplicatePattern,
reorderPage,
exportPattern,
permanentlyDeletePost,
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're going to export actions and fields from the same package, maybe we should consider suffixing these with Action?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, my idea is to have a structure like this Action.

const duplicatePost: Action< BasePost > = {
id: 'duplicate-post',

For instance, the duplicatePost action will be duplicateBasePostAction.

Copy link
Member

Choose a reason for hiding this comment

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

I'm a bit confused about why this exports actions. How you all envision the wordpress/fields package? If it's about fields, it should only export fields (see suggestion). If it's about dumping every WordPress-related thing we have in DataViews, wouldn't it be best to use a name that communicates that better?

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 think that the @wordpress/fields will expose all the components/actions necessary for WordPress Core - we discussed this here.

Nothing to document.
### duplicatePattern

Undocumented declaration.
Copy link
Contributor

Choose a reason for hiding this comment

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

Would be cool to add some placeholder JS Docs for these to avoid the "Undocumented declaration". We can definitely do that in a separate PR though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After wrapped up the migration, I will:

  • add JSDocs
  • update file name and action name (as I described here)

@@ -0,0 +1,5 @@
export { default as viewPost } from './view-post';
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need the "base-post" folder?

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 don't have a strong opinion, but I explained why I structured it in this way in the PR description! Happy to revisit it!

Copy link
Contributor

Choose a reason for hiding this comment

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

I like to start flat personally in general but I don't mind if you prefer it this way.

@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 12, 2024
@gigitux gigitux marked this pull request as ready for review September 12, 2024 13:29
Copy link

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: youknowriad <youknowriad@git.wordpress.org>

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

@gigitux
Copy link
Contributor Author

gigitux commented Sep 12, 2024

I fixed the CI steps regarding mobile version with ae0efeb and f7f1d4d.

This PR is ready to be merged! Thanks for the review! 🙇

@youknowriad youknowriad merged commit d329bfb into WordPress:trunk Sep 12, 2024
59 checks passed
@github-actions github-actions bot added this to the Gutenberg 19.3 milestone Sep 12, 2024
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.

3 participants