-
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
[Fields] Migrate store and actions from editor package to fields package #65261
Conversation
85d4fc0
to
67ff043
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.
The deleted code has been migrated to the @wordpress/fields
package
packages/fields/src/store/actions.ts
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.
The commented code has not yet been migrated to the editor
package. I will complete the migration in a subsequent pull request.
packages/fields/src/types.ts
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.
Copied-pasted from packages/editor/src/dataviews/types.ts
@@ -0,0 +1 @@ | |||
declare module '@wordpress/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.
This is necessary because @wordpress/editor
package isn't a TypeScript 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.
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 ); |
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.
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.
Oh ok! Gotcha! Also, in the case of the 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):
👍 It makes sense! I will update the PR! |
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, |
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.
If we're going to export actions and fields from the same package, maybe we should consider suffixing these with Action
?
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.
Yeah, my idea is to have a structure like this Action.
gutenberg/packages/fields/src/actions/base-post/duplicate-post.tsx
Lines 30 to 31 in 3616964
const duplicatePost: Action< BasePost > = { | |
id: 'duplicate-post', |
For instance, the duplicatePost
action will be duplicateBasePostAction
.
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 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?
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 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. |
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.
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.
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.
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'; |
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.
Do we need the "base-post" folder?
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 don't have a strong opinion, but I explained why I structured it in this way in the PR description! Happy to revisit it!
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 like to start flat personally in general but I don't mind if you prefer it this way.
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. |
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 theBasePost
type.common
contains all the actions for thePost
type (that it is an union type).pattern
contains all the actions for thePattern
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:
reset-post.tsx
:gutenberg/packages/editor/src/dataviews/actions/reset-post.tsx
Line 45 in 0e671a2
duplicate-template-part.tsx
:gutenberg/packages/editor/src/dataviews/actions/duplicate-template-part.tsx
Lines 53 to 54 in 0e671a2
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