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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: talldan <[email protected]>
Co-authored-by: tellthemachines <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: mcsf <[email protected]>
Co-authored-by: oandregal <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +2.81 kB (+0.15%)

Total Size: 1.93 MB

_{compressed-size-action}

Flaky tests detected in 9bca0d4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17452663904
📝 Reported issues:

• [Flaky Test] passes the search value in the main inserter when clicking Browse all #45332 in /test/e2e/specs/editor/various/inserting-blocks.spec.js

Nice work @talldan

In manual testing selection is working well, and how I'd expect it. Thanks for getting things started.

The only question that sprung to mind in relation to the abstraction — bearing in mind I'm still a Dataviews dilettante — what would be an example of its usage in conjunction with Dataviews? Would consumers pick one component or the other or would the <DataPicker /> be mounted based on an action if required? Or is the plan just to test out the API and eventually subsume DataPicker into Dataviews?

I know this was the feedback to create a new component. It just makes me wonder how it all squares with Dataviews' already built-in selection functionality and if we're building "around" an inadequacy.

Sorry if I'm way off, just typing things out 😄

Supporting selection across pagination. Individual selection does work across pages, but 'Select all' doesn't (since in the code we don't know the IDs for all of the items). Perhaps this is ok, open to feedback on whether we should try to support it.

My 2c: I think we'd need to first answer whether users expect "Select all" to work across paginations at all.

Speaking only for myself, when I see "Select all" on a page, I understand it to mean "select all items currently visible" or, "I know I'm working with what I can see".

As far as I can tell this is the standard pattern in apps like Gmail and GitHub 🤷🏻

If the Datapicker allows bulk operations on filtered subsets then that's already a powerful feature, so, unless there's a requirement with sound rationale, I personally don't believe the complexity is worth it.

In manual testing selection is working well, and how I'd expect it. Thanks for getting things started.

+1, also looking at the PR, I do like the idea of an opinionated DataPicker component that's kind of pre-set up for the picking use case 👍. Just sharing a couple of quick thoughts that came to mind:

While testing, I felt like we also need the "cog" icon / sort by drop down that DataViews uses, too?

Another challenge with having separate views, is that I imagine if this component is used for something like a post parent picker or a modal for selecting page links, etc, that we'd also really want a Table view for browsing and selecting while viewing more of the fields. So if we have (semi) duplicate Table and Grid views, will that be a challenge for maintenance / ensuring things are always compatible?

Speaking only for myself, when I see "Select all" on a page, I understand it to mean "select all items currently visible" or, "I know I'm working with what I can see".

Yes, personally I'd expect "Select all" to only refer to the items currently in view, and not span across pagination.

Would consumers pick one component or the other or would the be mounted based on an action if required?

Rather than having the separate DataPicker component, I think it could potentially be another view of the DataViews component, but there are some parts that don't quite work:

• DataViews has a lot of extra props that don't mean anything to DataPicker - for example isItemClickable, onClickItem, actions, renderItemLink.
• DataViews has some opinionated pieces around how selection works. The selection array is filtered here so that it doesn't work across pagination. We'd need to find a way around that constraint.
• The DefaultUI (particularly the footer) that DataViews comes with doesn't work for a picker, so we'd need a way to switch the footer based on the type of view.

It just makes me wonder how it all squares with Dataviews' already built-in selection functionality and if we're building "around" an inadequacy.

The way it works right now you can still reuse parts of dataviews - the search, pagination are shared, it's the view and the bulk selection parts that are different. I think this is the part where I don't feel the abstraction is quite right in the PR because of the way DataPicker is presented as a sibling of DataViews but is also inheriting parts (this is a weird analogy!).

So if we have (semi) duplicate Table and Grid views, will that be a challenge for maintenance / ensuring things are always compatible?

Yep, I think we will have duplicates, but then internally/semantically I expect they will be quite different. Also I think there's the potential for the presentation to be very different.

We can also try extracting some aspects of the implementation to be usable by both. For example the grid layout might be something we consider extracting so the grids always have the same sizing/responsiveness.

It might help to think about (maybe even try out) some different use-cases

One use case in the back of my mind is to be able to support browsing from and choosing a page parent for sites with a very large number of pages (e.g. enterprise or large knowledge bases). There's an issue in #69608 that the current approach maxes out at 100 pages, so for larger sites I could imagine the DataPicker in a modal being really handy for being able to browse, search and sort before selecting a parent (particularly since it supports pagination).

Choosing media or patterns is another use case in WordPress. We have this modal at the moment for patterns, which doesn't have any kind of searching or pagination, and there might be quite a lot of patterns, especially if we support user created patterns in this view in the future:

Hey, I'm trying to understand what's this for and why DataViews can't be used. Would this be a good breakdown of what we need in a picker, or did I miss something?

• hide controls: search, filters, view config
• prominent CTA for confirming selection (bulk selection of a single item without the action menu in each item)
• keyboard navigation: easy selection

I'd like to offer an alternative direction that leverages the existing DataViews component instead of creating a new one.

• Hide controls
  • Search: already possible (DataViews.search set to false)
  • Filters: already possible (fields.filterBy set to false)
  • View config: not possible to hide right, but we require this in other use cases as well (I've seen a table without any header controls). Implementing this solves many use cases.
• Prominent CTA:
  • Alternative 1: can't this live outside DataViews, like we have in the site editor?
  • Alternative 2: can we leverage the existing "Action.context" to render some actions only as the Selection CTA? There may be other alternatives as well.

Keyboard navigation: both improvements are useful to DataViews grid independently of what we do with pickers, so it'd be good to have them anyway.

• Select item. Can we change the SPACE key in DataViews Grid layout to select the item while leaving ENTER to click on it (if the item is clickable)? Actually, this already works as expected when the item is not clickable.
• Speed navigation via arrow-keys. Can we implement this in the DataViews Grid layout as well? Also, I think the behavior should be a grid (support for both right-left navigation and top-down via arrow keys).

Using the existing DataViews, this is where we stand visually (in red what we need to resolve):

@oandregal some previous discussions here #70722 (comment)

@youknowriad I saw that but didn't see a breakdown of the specifics. Are we settled on a separate component, or is it open to discussion? Based on the breakdown above and unless I've missed some other task, I don't think it's too hard to make DataViews work in that use case.

I don't think we're totally settled but I'm personally almost there :P The two arguments for me are:

• How would a "kanban" view work for selection? Not all layouts make sense for both use-cases. One is about rendering data, the other is about selecting an item (and that's it).
• The semantics feel different. I don't want to be able to trigger random actions in a "picker".

I also know @ellatrix tried to use DataViews list view for a "picker" once (Site picker in calypso I think) and she reverted because it just didn't fit. Curious if you remember the specifics.

How would a "kanban" view work for selection? Not all layouts make sense for both use-cases. One is about rendering data, the other is about selecting an item (and that's it).

Every layout doesn't have to work for every purpose. That's why we have the configuration. For example, the list layout doesn't work well without a preview and that's fine.

The semantics feel different. I don't want to be able to trigger random actions in a "picker".

This is just configuration to me: the DataViews' actions prop is a single action with a context.

Would this be a good breakdown of what we need in a picker, or did I miss something?

Some might be bugs, yet to be implemented or some might work that way for a reason, I don't know the history:

• Selection doesn't work across pagination, which is a must have for a picker.
• The selection API doesn't work without a bulk action, so an external CTA is currently not possible.
• Multi-selection requires holding ctrl/cmd key when clicking items - when the primary purpose is as a picker, I don't think the modifier key should be required.
• Missing aria roles, labels and attributes like aria-selected, aria-posinset, aria-setsize - some of these might also be specified differently depending on whether the dataview's purpose is as a picker, or as a general dataview.

I don't think there's anything that can't be solved, whether it's configuration or a dedicated component. If it's achieved via configuration, the question is how granular that configuration is, and whether we can avoid introducing options that don't make sense when used together. I think that's the main advantage of a separate component is that it can be more prescriptive in its interface.

Speed navigation via arrow-keys. Can we implement this in the DataViews Grid layout as well? Also, I think the behavior should be a grid (support for both right-left navigation and top-down via arrow keys).

It's a topic, but I'm not convinced on grid navigation. Not that being able use arrow keys in all directions wouldn't be good, but the aria implementation for grid seems really lacking tbh, and the examples don't seem to fit the use case. I expect screenreader support is terrible too. Those of us that worked on keyboard navigation for ListView in the editor ran into these sorts of issues, and in the end we had to use role=application for it.

If there's a simpler option, like making it a list, then it might be an easier starting point.

Also, I'm not sure how things like setting a sort order make sense if the thing is semantically a grid. What does it mean to sort a grid.