Conversation
|
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. |
|
Size Change: +60 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
mcsf
left a comment
There was a problem hiding this comment.
Quick thoughts:
- I think introducing
contextmakes sense - But I worry about overloading WordPress's preexisting
edit|viewdichotomy with something that is close but not quite like it - I wouldn't dismiss
context: 'list'too quickly: there may be something worthwhile there
| const actions = useMemo( () => { | ||
| if ( type === TEMPLATE_PART_POST_TYPE ) { | ||
| return [ editAction, ...templatePartActions ].filter( Boolean ); | ||
| return templatePartActions.filter( Boolean ); |
There was a problem hiding this comment.
Is filtering still doing anything useful? I'd be surprised if usePostActions were returning empty values.
ffa2496 to
a388f2e
Compare
a388f2e to
bde1cc4
Compare
|
|
||
| const postRevisionsAction = { | ||
| id: 'view-post-revisions', | ||
| context: 'list', |
There was a problem hiding this comment.
I know we only support one context right now, but I expect this will grow and we may endup with more contexts. Would it make sense for context to be array with all the supported contexts?
There was a problem hiding this comment.
Nothing is public right now, so I think we can add it when we'll need it.
jorgefilipecosta
left a comment
There was a problem hiding this comment.
I think we can merge this solution it seems very likely we will need a context for the actions, and we can iterate in the future how that context looks like.
|
This PR was cherry picked for 6.6. |
What?
Related: #62323 - in the aspect of not showing the
revisionsaction ineditmode.This PR proposes the addition of a new
contextprop in post actions API. Post actions in their majority are meant to be used in any context like in data views (lists) or in editors as part of the ellipsis menu in inspector controls. There are some exceptions though and a couple examples are:editPostaction which doesn't make sense in the editors, as we already editing. For that reason this actions lived in edit-site package and was separated from all the other actions that live ineditorpackage (for now).My suggestion for the new
contextproperty values is a separation betweenlistand whatever view/layout might use them in the future... Due to the unification of editors I don't think it makes sense to consideredit-post|edit-siteetc.. and also experimented withedit/viewcontext but the lines might blur when we havelistviews with editing allowed. It's a private API, so we can always revisit.A consumer of actions in order to get them from where ever (right now with
usePostActionshook) can provide a specific context if needs to, but the absence of it means fetch all (default). Additionally actions can provide a context where they are allowed and is separate fromisEligible, as it's meant for checks regarding a specific item.I'd welcome any feedback and suggestions about the API.
Testing Instructions
edit postaction