-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
DataViews: Allow actions to be provided declaratively as a prop #55192
Conversation
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.
Thans Riad! This is similar to what I had in mind for actions too. Noting that PageActions
component was being reused in the single page view in site editor(navigation sidebar action next to the title).
Interesting, I wonder if this should be a dedicated reusable component that the data views package provide or if it's something custom. I think for a start, I'll go with custom component (just leave the existing one), but it's going to be interesting to see how that maps to the "actions" in the Data views long term. |
There's some duplication right now but I think it's better to start with duplication for this menu for now. |
Size Change: +430 B (0%) Total Size: 1.65 MB
ℹ️ View Unchanged
|
Any ✅ here |
Is this working for you? This is what I see: Gravacao.do.ecra.2023-10-10.as.18.53.26.mov |
import { useMemo } from '@wordpress/element'; | ||
|
||
export default function useMoveToTrashAction() { | ||
const { createSuccessNotice, createErrorNotice } = |
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 was thinking the actions would only be responsible for interacting with the data
(remove, edit, etc.) and they'd have success and failure callbacks for the UI to handle them as it wishes.
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.
It's hard for me at this point to know what actions are going to be about. I'm guessing actions can be anything that takes the current "item" as argument and do anything:
- Export
- Duplicate
- Edit
- Open modals (rename)
- Download
I think it's very hard to predict what actions would want to have access to and what flows they will trigger.
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 agree -- I think it makes sense to let each action handle the complete process (including showing/changing UI) for the time being until more patterns are recognized.
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.
Actions will need to do more and in follow ups we will probably need to change label
to be a component to be able to render modals, etc..
return ( | ||
<DropdownMenu | ||
icon={ moreVertical } | ||
label={ __( 'Actions' ) } | ||
className={ className } |
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.
It seems PageActions
with the className
property was introduced a while ago at 375b16f Probably best to leave the component as it is?
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.
It's not used in any of the usage of PageActions. a bit of cleanup :)
@oandregal Good catch, I fixed the issue. I had used "postType" instead of "type" :) |
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.
Thanks Riad! The thing not working properly here is when we delete a page, we should trigger the pagination info to be updated too. This will be fixed when merged because in trunk there is the update for getting this info from useEntityRecords.
Related #55083
What?
This is a small refactoring/API PR that extracts the "actions" property of the data views into a dedicated prop instead of leaving it as part of "fields".
The reasoning is simple:
Testing Instructions