-
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: sort author by name + allow custom sort function #64064
Conversation
Size Change: +2.14 kB (+0.12%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
view.sort?.direction ?? 'desc' | ||
); | ||
} | ||
|
||
if ( | ||
typeof valueA === 'number' && |
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.
Note that I've left the existing logic here because type
is optional. When/If make it required this could be removed.
fbddc9c
to
4460490
Compare
return integer; | ||
} | ||
|
||
// If no type found, the sort function doesn't do anything. |
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 do we think of this? What do we do if the type is not found?
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. |
@@ -0,0 +1,20 @@ | |||
/** |
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.
Nice file :)
Should we move the "control" to the field types definition?
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.
Yes! And validation, etc. I'll do that in a follow-up.
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.
Validation moved to the type definition at #64164
packages/dataviews/src/types.ts
Outdated
a: Item, | ||
b: Item, | ||
direction: SortDirection, | ||
getValue: ( args: { item: Item } ) => any |
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 should remove getValue
from here. It's redundant with the field itself, we're defining the field here. Instead we should update the "normalize" function to inject it when we fallback to the field type sort function.
itemA: Item, | ||
itemB: Item, | ||
direction: SortDirection, | ||
getValue: ( args: { item: Item } ) => any |
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 thinking a bit more here, I think we shouldn't pass getValue
here at all, we should just pass valueA
and valueB
that are both integers (instead of itemA and itemB). At this point (field type), there's no need to know about the item or the field or anything.
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 pushed eaa0b63
I like this more than previous approaches and it could scale well. For example, in validation, the field types such as integer would need to have access to elements
as well, so we'd add that.
It's not entirely perfect, though: a generic field type such as integer
doesn't know the "id" of the data it's working with so the item
parameter there is useless.
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.
Passing only the values is how I started. The trade-off with that approach is that it presumes the custom sort function wants to access data that's defined elsewhere, but it may want to access data that comes as part of the item (see author custom function).
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.
Passing only the values is how I started. The trade-off with that approach is that it presumes the custom sort function wants to access data that's defined elsewhere, but it may want to access data that comes as part of the item (see author custom function).
This is only true for field.sort
not for fieldType.sort
where you always want to use the data.
Flaky tests detected in eaa0b63. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10161069692
|
direction: SortDirection, | ||
getValue: ( args: { item: Item } ) => any | ||
a: { | ||
item: Item; |
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.
Why have Item here at all? I was thinking a: any, b: any
should be sufficient no?
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 see what you did, I think you're misunderstanding what I'm suggesting. I'm suggesting that fieldType.sort
and field.sort
to have different APIs. one receives the items, the other receives the values. Do you want me to try to commit what I have in mind?
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.
@youknowriad please, be welcome to push. In my mind both functions are instances of the same idea, so they'd have the same signature. But I'm open to try different things: push and we can discuss what's there.
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.
For me field types and fields work at different levels, field types work on values, fields work on items, so it doesn't make sense to have the same API.
I've pushed what I had in mind in 621ac69
Feel free to revert if you don't like 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.
621ac69 works for me.
What?
This PR sorts author by name instead of id. It does so by also allowing fields to provide a custom sort function.
Why?
Author ids don't mean anything to users, we should sort it by name.
Note that the REST API allows sorting by author but it really sorts by "author id". The wp-admin doesn't allow sorting the post/page list by author.
How?
integer
, which provides a default sorting function.Testing Instructions
The expected result is that the order is pages created by alpha, then beta, then gamma. In
trunk
, the order is by id (this is: alpha, gamma, beta).