Update: Move template actions to the editor store.#60395
Conversation
|
Size Change: -288 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
e0c5238 to
826b965
Compare
|
Flaky tests detected in d763c671f58480cbf0e4aac69ecba3e236ff6bf9. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8602162792
|
|
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. |
23ffe3a to
57f457c
Compare
e44d04d to
454d2a0
Compare
mcsf
left a comment
There was a problem hiding this comment.
Left some notes and a recommendation, but other than that LGTM!
| async ( { registry } ) => { | ||
| await unlock( registry.dispatch( editorStore ) ).removeTemplates( [ |
There was a problem hiding this comment.
(minor question) Is the async/await structure necessary here? We're just delegating to a private action, so I'd've expected something like removeTemplate = tpl => unlock( ... ).removeTemplates( [ tpl ] ). Or is it to signal something to the reader?
There was a problem hiding this comment.
Yes, we can just return and I updated the code. But it is a fact that async await provides a better signal to the reader that the action is async, but we don't do it in other parts of the code so we can just return here as well.
| "@wordpress/compose": "file:../compose", | ||
| "@wordpress/core-data": "file:../core-data", | ||
| "@wordpress/data": "file:../data", | ||
| "@wordpress/data-controls": "file:../data-controls", |
There was a problem hiding this comment.
The IDE automatically added a wrong import the line was removed.
| }, | ||
| }; | ||
|
|
||
| export const resetTemplateAction = { |
There was a problem hiding this comment.
(I don't remember if I have already asked this question) Why are we exporting these actions? Unless there is a present need, let's hide them and only expose usePostActions, no?
There was a problem hiding this comment.
Yes, I missed this on the other PR, the exports were removed.
Similar to #60092.
This PR moves the template actions to the editor package.
It will allow actions like reverting a template to be available on the post editor (the post card panel at the top when editing the template will show the actions).
To move the "template actions" two store actions also needed to be included in the editor package.
Testing
Open the templates section and verify actions and bulk actions still work as before.