-
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
DataViews: label
prop in Actions API can be either a string
or a function
#61942
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: +117 B (+0.01%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
Flaky tests detected in 4274b02. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9269058081
|
@@ -470,7 +470,15 @@ const viewPostAction = { | |||
|
|||
const postRevisionsAction = { | |||
id: 'view-post-revisions', | |||
label: __( 'View revisions' ), | |||
getLabel( items ) { |
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.
What if instead of a new property getLabel, we just make the label string | ReactComponent
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.
A React component would allow calling selectors, hooks ... in additional to using the "items".
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 didn't want to mix a prop with such different types, but don't have a strong opinion on this. A component could do that, but we use the label in specific internal components that render the actions and they expect a string returned value.
Do you think it would be enough to add docs that we support a label component, but expect a string value?
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.
they expect a string returned value.
What are these places?
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've just looked into the dataviews package, and I think we can support components in all the places where action.label is used now. That said, I would not mind having other opinions here. For block types, we have __experimentalLabel
which is basically always a component that is kind of equivalent.
Any thoughts @mcsf @ellatrix @jorgefilipecosta
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.
they expect a string returned value.
Sorry, I should rephrase.. What I meant is that the label is used in places (menu items, tooltips, modal header title, etc..) that expect a final 'string' value - not per JS type per se. So while we can support components technically, personally I'd rather not do it from the start to try to keep consistency of the UI that is handled by the internal packages and not third party consumers.
__experimentalLabel
is equivalent yes, and also returns a string
value in our codebase. If we returned something different - that we could - it would definitely create problems in UI. if you see most of the implementations of this callback it's either passed the block attributes, which is like our selected items or have a hook to get the current entity.
So, while I don't have a strong opinion to use a component, I'd rather we are just as flexible as we need right now. I don't think we have a use case right now for needing components, do we?
items[ 0 ]._links?.[ 'version-history' ]?.[ 0 ]?.count ?? 0; | ||
return sprintf( | ||
/* translators: %s: number of revisions */ | ||
__( 'View revisions (%s)' ), |
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.
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.
Things work well on this PR, and the code looks good. I'm ok with a getLabel function for now that just returns a string if needed in the future we can always switch to a component to allow hooks usage etc.
My only doubt is if the number of revisions should be shown as part of the label or as suffix but that's a design question, from the code point of view things look good.
The label is not used only in TBH, having a component or getter is a small detail (although I prefer a simple function). What I'm not sure after @youknowriad 's comment is whether we should keep two props for getting the label or having one that could be a string or a function. I'm still leaning towards two props for clarity, but no strong opinion. |
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 we can merge things as they are and if needed iterate later on the design or API.
I don't like the two properties for the same thing but it's fine by me. |
4c3b603
to
871c894
Compare
packages/dataviews/README.md
Outdated
@@ -241,7 +244,7 @@ Collection of operations that can be performed upon each record. | |||
Each action is an object with the following properties: | |||
|
|||
- `id`: string, required. Unique identifier of the action. For example, `move-to-trash`. | |||
- `label`: string, required. User facing description of the action. For example, `Move to Trash`. | |||
- `label`: string|function, required. User facing description of the action. For example, `Move to Trash`. In case we want to adjust the label based on the selected items, a getter function which accepts the selected records as input can be provided. The getter function should always return a `string` value. |
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.
Besides this change, everything else was from auto formatting.
getLabel
in Actions APIlabel
prop in Actions API can be either a sting
or a function
label
prop in Actions API can be either a sting
or a function
label
prop in Actions API can be either a string
or a function
74f0f4a
to
4274b02
Compare
Apologies for not catching this, but do you think it would be feasible to use the |
|
Would it be massively over-complicating to include a separate prop for the tooltip content, so that you could specify:
|
I think it will add complexity at the API and TBH I'm not sure it will add much value in general for every action. Do we see many more actions to have something similar? If we update the actions rendering in the future, would that API make sense? So, I think while we could explore this and try to evaluate an API for splitting labels, suffix etc.., I don't think it's something that could be done for 6.6, given the timeline. |
…`function` (WordPress#61942) Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
…`function` (WordPress#61942) Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Related: #61867
This PR allows
label
prop in Actions API can be either astring
or afunction
, in case we want to use information from the selected items. The function accepts the selected items, in case an action wants to modify the label based on that information.It makes more sense for non bulk actions and in this PR is used for the post revisions action to also display the number of available revisions.
Since the action's label is used mostly in places that expect a string, I think it makes sense not to have a component, but just a callback that accepts the selected items and returns a
string
.Testing Instructions
Ensure that actions and their labels work properly:
The only visible change from this PR is that post revisions action label includes the number of the revisions.