Add author and status filter to the page list #55270
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oandregal
added
[Type] Feature
oandregal
commented
Oct 11, 2023
youknowriad
reviewed
Oct 12, 2023
oandregal
force-pushed
the
add/filters-page-table
branch
from
38bb4ee
to
3c5db11
Compare
|
Size Change: +387 B (0%) Total Size: 1.66 MB
ℹ️ View Unchanged
|
oandregal
force-pushed
the
add/filters-page-table
branch
from
3c5db11
to
01a2533
Compare
oandregal
commented
Oct 13, 2023
|
For posterity, this is the raw first attempt at implementing the current design direction for filters UI (as per the mockups here): Gravacao.do.ecra.2023-10-11.as.17.28.06.mov |
|
I've switched gears from implemented the field filters in the main toolbar (see previous attempt) to add filters as part of the column actions. It feels a better "first UI version" we could ship: Gravacao.do.ecra.2023-10-13.as.13.36.14.movNext, I'd like to show which column filter is active in the top toolbar. Working on this UI direction surfaced interesting questions, such as this one: each column could actually be filtered in different ways, being the "text search" the fallback for any filterable column. For example, the "author" column could be filtered by the given list of existing authors, but it could also be interesting allow "text search": 
Note that text search is not implemented. I just wanted to show the possibilities. |
|
Flaky tests detected in 0d68580. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6511386897
|
oandregal
commented
Oct 13, 2023
| @@ -66,6 +68,10 @@ export default function PagePages() { | |||
| totalPages, | |||
| } = useEntityRecords( 'postType', 'page', queryArgs ); | |||
|
|
|||
| const { records: authors } = useEntityRecords( 'root', 'user', { | |||
There was a problem hiding this comment.
We don't need to have this data up-front, only when the user goes to filter (or edit cells, in the future). This data could be lazy loaded upon events (opening the filter menu, etc.). Leave the comment here as food for thought to be addressed in follow-ups.
There was a problem hiding this comment.
In general this is a filter that we shouldn't pre load all records, not only for performance, but also about the REST API limits to 100.
There was a problem hiding this comment.
My comment is a bit stale, since the approach has changed: the filter is now always present in the UI (before it was only visible as part of the columns' actions). Does that change your thinking? What should we do here instead?
|
Current status: have IN and NOT IN filters working with a single author. Gravacao.do.ecra.2023-10-13.as.19.42.29.mov |
|
Thanks for the ping @oandregal . As a starting point what we could do to keep things simple is to have a set of persistent primary filters at the top next to search. We can then work towards the action of adding extra filters as a follow up task.
|
ntsekouras
reviewed
Oct 17, 2023
ntsekouras
reviewed
Oct 17, 2023
oandregal
force-pushed
the
add/filters-page-table
branch
from
0d68580
to
ab2a8fd
Compare
youknowriad
reviewed
Oct 17, 2023
youknowriad
reviewed
Oct 17, 2023
The Select component works either with scalar or arrays. We cannot mix both.
oandregal
force-pushed
the
add/filters-page-table
branch
from
58baefc
to
14b2ab8
Compare
I implemented this #55270 (comment) That's great feedback, thanks! |
youknowriad
reviewed
Oct 17, 2023
| @@ -126,6 +133,7 @@ export default function PagePages() { | |||
| </VStack> | |||
| ); | |||
| }, | |||
| filters: [ { id: 'search', type: 'search' } ], | |||
There was a problem hiding this comment.
I don't think the "search" is the same thing as "title". One is a "global search" that searches in multiple fields and not just the "title".
There was a problem hiding this comment.
I agree, search is different from the other filters.
I shared some thoughts in this thread. The way I see it, search is a multi field filter that searches across post_title, post_excerpt, and post_content while the other filters use a single field. Note that search can also be single-field if search_columns is set to post_title. It's a bit weird. Conceptually, all of them are filters and share the same characteristics: endpoints may or may not allow a dataset to be filtered by this type of filter, the endpoint query parameter can be different, the user should be able to hide/show the filter, etc.
We may need a special treatment for filters like this one. I know tanstack differentiates between global and column filters, but I'm not sure if that's enough for us. We may need more granularity, allowing filters to declare in which context they should be rendered: top-level, table view (columns), grid view, kanban, etc.
I'd like to stretch it a bit and see how far it gets us. I'll prepare a follow-up to explore rendering the filters in the columns, and that should inform the needs for this API.
There was a problem hiding this comment.
Extracting search out of fields at #55475
youknowriad
reviewed
Oct 17, 2023
| }, | ||
| { | ||
| header: __( 'Status' ), | ||
| id: 'status', | ||
| accessorFn: ( page ) => | ||
| postStatuses[ page.status ] ?? page.status, | ||
| filters: [ { type: 'enumeration', id: 'status' } ], |
There was a problem hiding this comment.
I think the "id" here is a bit weird, it seems to just duplicate the field id for me.
There was a problem hiding this comment.
#55440 addresses this.
youknowriad
reviewed
Oct 17, 2023
| }, | ||
| { | ||
| header: __( 'Status' ), | ||
| id: 'status', | ||
| accessorFn: ( page ) => | ||
| postStatuses[ page.status ] ?? page.status, | ||
| filters: [ { type: 'enumeration', id: 'status' } ], | ||
| elements: [ | ||
| { label: __( 'All' ), value: 'publish,draft' }, |
There was a problem hiding this comment.
Why are we limiting to "publish" and "draft"? There might be more statuses like "schedule"... Why not use the REST API for this. Also, why "all" has a value and not just "unset" the filter.
I also believe the "all" could be added automatically and not provided in this elements config.
There was a problem hiding this comment.
Why are we limiting to "publish" and "draft"? There might be more statuses like "schedule"... Why not use the REST API for this. Also, why "all" has a value and not just "unset" the filter.
I don't know. This was in the original query. If all statuses are used, we don't need to provide the "unset" value for the endpoint. I'll look into this in a follow-up.
I also believe the "all" could be added automatically and not provided in this elements config.
This is addressed at #55440
There was a problem hiding this comment.
Listing pages with any status at #55476
youknowriad
reviewed
Oct 17, 2023
| import TextFilter from './text-filter'; | ||
| import InFilter from './in-filter'; | ||
|
|
||
| export default function Filters( { fields, view, onChangeView } ) { |
There was a problem hiding this comment.
I like this new component
This was referenced Oct 18, 2023
26 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related #55083
What?
Allow filtering by author and status:
Gravacao.do.ecra.2023-10-17.as.13.59.30.mov
Testing Instructions
Test the filter works as expected. Only the pages with
publishanddraftstatuses are shown, as before.Next
Follow-ups (can be done in parallel):
enumerationfilters (authorandstatus).NOT INfilters (the current ones areINfilters) at the top-level. For example, useauthor_exclude.searchfilter to be limited to one ofpost_title,post_excerpt,post_content. At the moment, it searches in all them.searchcould work differently. DataViews: passsearchfilter as global, unattached from fields #55475publishanddraft. Dataviews: list all pages, not only those with publish and draft statuses #55476