Repository navigation
DataViews: support true hierarchical nesting with expand/collapse #80360
Description
What problem does this address?
DataViews can currently only represent hierarchy as visual indentation — child items are prefixed with em-dashes (—), mimicking WP_List_Table. This isn't real nesting:
- There's no true expand/collapse tree for nested items (e.g. category → subcategory → sub-subcategory).
- At scale, a flat list of hundreds of nested items is unmanageable — everything is always visible, with no way to focus on a single branch.
- Indentation alone (the "em-dash" faking) signals depth but doesn't let you collapse a parent, and it degrades across pagination, sorting, and search.
What is your proposed solution?
Introduce a genuine hierarchical tree in DataViews (table layout only), with a disclosure chevron on each parent row to expand/collapse its children, so deep structures can be navigated without rendering everything flat. Below, I break down the proposal.
Prototype
https://hierarchical-nesting.vercel.app/
I'm experimenting with Categories to see how the pattern works and scales in more complex scenarios like taxonomies. The prototype only shows a proposal for the parent–child relationship. You can switch between the different options outlined below by clicking the "States" pill at the bottom left.
Affordance (expand/collapse control)
Hierarchical.nesting.-.Affordance.mov
Chevron on the left: common pattern across products, but it offsets the whole table. If manual reordering is added in the near future (which is needed), the left side could get too crowded with actions. If we go this direction, one idea proposed by @JanaMW27 and @fcoveram) is a "master" chevron in the header that expands/collapses all elements at once.
Chevron after the title: either inside the count badge or standalone. Better for table alignment, but there are concerns about making the badge interactive, since that's not an established pattern. If child counts can't be detected, the badge goes away and we fall back to a standalone chevron after the title. Note that titleField in DataViews isn't required, so the chevron/badge would attach to the first available field.
Sorting
Sort within each level: top-level items are sorted together, and each parent's children are sorted within that parent. A flat, global sort would separate children from their parents and break the tree.
Pagination
Drop the items-per-page setting, since it's a flat-list concept that doesn't map to a tree. That's separate from pagination as a mechanism: we still need a per-level "load more" so a single parent with many children — or a very large top level — stays bounded.
Counts & totals
Need to confirm whether the APIs can reliably identify the number of children. If that's a promise the lazy data layer can't keep, we should drop the counts.
Search
Search behaves as a distinct view: a flat result set where each match carries its ancestor path in breadcrumb form, so users can see where an item lives without rendering the full tree. It spans all pages, not just currently visible items.
We also explored rendering the full tree in the results, but ruled it out — it forces constant reloading and the UX gets very complex for little benefit. That narrows the options to three, all flat and breadcrumb-based:
- Two lines: match on top, path underneath.
- Ancestors before, one line: full trail, match at the end.
- Ancestors after, one line: match first, path trailing.
Hierarchical.nesting.-.Search.mov
On smaller screens, the two-line option is the only viable approach.
Open questions
- Affordance: chevron on the left vs. after the title, and whether the count badge should be interactive — plus whether to add a "master" expand/collapse chevron in the header.
- Counts & totals: can the APIs reliably return the number of children?
- Search result display: which breadcrumb layout — two-line, ancestors-before, or ancestors-after? (Two-line is the only one viable on small screens.)
- Anything else?
Activity
jasmussen commentedon Jul 20, 2026
This is wonderful work, I fully endorse it. Thank you for the powerful contribution.
I'm not personalyl convinced about the child counts, and I do think technically it might cause performance issues on sites with thousands of pages, but that's a soft nitpick and not a blocker from my end.
I would invite broad feedback on this, and hoping someone can help pick it up. CC: @WordPress/gutenberg-design
keoshi commentedon Jul 22, 2026
Ditto what Joen said above: this is excellent work, @verofasulo! Love the simplicity of the solution you landed on, especially taking into account the complexity of the problem.
For the nesting, I really dig "Chevron on the left + header". My first instinct when looking at the first option was wondering if these lists would benefit from a expand/collapse all action, and I was delighted at the elegant solution of having a global chevron in the table header. Simple and effective.
Purely from a visual standpoint, I do prefer “Chevron only”, but also appreciate the counter inside each row that give an overview without any extra clicks. Visually something's off about it (maybe having a lot of horizontally stacked elements in a row), but the functionality-wise it feels crucial.
In terms of search results, I'm a big fan of "Flat search - 2 lines". Super clean and feels the clearer way to indicate belonging without being visually complex.
Two aspects of the UX that feel worth surfacing:
Interactive areas
Especially in the "Chevron on the left + header" alternative, there are a lot of actions condensed into a very small horizontal space:
And this list is just on the first column. Doesn't take into account other columns where individual items might carry their own interactions or the actions column. The fact that the Categories/Tags/Custom Taxonomy page is now full-width should help alleviate the horizontal constraint a bit, but maybe some of the other cleaner options ("Chevron in the badge" or "Chevron only") are worth testing first.
Selection
Noticed that selecting a parent doesn't select its children. Usually, ticking a parent selects the entire subtree. Similarly, unticking any child item, or ticking only some of them, drops the parent out of the fully-checked state into an indeterminate state (checkbox with a line
-).The desired interaction here might depend on what objects are being presented. For example, certain taxonomies could warrant the entire sub-tree to be selected, while other objects perhaps wouldn't. It would be good to define what this interaction looks like for most cases and apply it universally.
fcoveram commentedon Jul 28, 2026
Great great exploration Veronica ✨
The TL;DR I lean on is:
I don't have much to say about the interaction nuances as WordPress components address the use cases I have in mind.
For the breadcrumb in flat search, we should tap into the breadcrumbs component from @wordpress/admin-ui. Improving the responsiveness there would benefit both elements and makes the maintainance easier.
Have you considered showing the nestation without the expand/collapse control? The current in wp-admin and site admin already show this.
Have you considered how manual order and automatic sort can work together? I acknowledge it’s not part of what you’re exploring, but I’m wondering about interaction nuances with nested elements. The rule I’m thinking of is that when manual ordering is permitted, sorting by the column header should be a one-time action.
verofasulo commentedon Jul 29, 2026
Nice, it looks like we’re aligned on these two approaches!
@Filipe, 100%. If we also consider adding reordering functionality, the interaction complexity increases even further. At the same time, these are all common patterns in modern products, and I think users’ expectations of finding these functionalities outweigh the drawbacks of a more crowded interface. Wdyt?
That’s such a good point. I’d be curious to hear @ntsekouras and @gigitux ’s thoughts on this.
@francisco, that’s a nice idea. We’d need a smaller variant, though: the default is 15px, while a small or compact version could be 12px.
I also wouldn’t expect the items to be links, which is the current behaviour of the breadcrumbs component. I imagine them being static and communicating belonging and hierarchy rather than acting as a navigation component. Does that make sense to you?
@ntsekouras, I’d also be curious to hear your opinion on how we should approach this at the component level.
Do you mean offering both a nested parent–child view and an almost-flat view as alternatives? I don’t think the latter works particularly well, and it currently creates several issues, but maybe you've encountered use cases where the fully nested approach might not work as well?
Oh, that’s such a good point. @fcoveram Could you expand on what you mean by “sorting by the column header should be a one-time action”?
Would it work something like this: you click “Name” to sort alphabetically, and the rows visually rearrange in that moment, but the system doesn’t treat this as the new persistent ordering rule. The existing manual order is preserved underneath and remains the “real” order. If you refresh the page, add a new item, or navigate away and return, you would see the manual order again rather than the alphabetical one. Is that what you had in mind?
fcoveram commentedon Jul 30, 2026
Agree with you. For the size, I think it's possible to use the same component (perhaps not in its current state, as it needs to integrate the font-size prop) with
--wpds-typography-font-size-smto show 12px. Regarding the link, I think this could also be part of the breadcrumb component, as there are other cases where the breadcrumb path is only declarative and doesn't need to be interactive.Looking forward to seeing what other folks think of expanding breadcrumb component capabilities.
No. I meant reusing the "Chevron on the left" layout but hiding the expand/collapse action while keeping the indentation space to show there is a parent/child relationship. In the example I shared, that is conveyed by the
—symbol (one, or two, or more, depending on the level).It's similar to your example, but I will elaborate more to make sure we're talking about the same thing. I also found that spreadsheet addresses this very well.
CleanShot.2026-07-30.at.11.46.04.mp4
In a list of entries
Does this make sense to you?
verofasulo commentedon Aug 10, 2026
Yes, that makes sense to me and the video attached is such a good example. 🙂 It's Google Sheets, right?
I was checking Wix for other reasons and noticed they recently implemented subcategories. Sharing because it’s relevant to this stream of work, and it’s interesting to see that they landed on a direction very similar to the one we’re leaning toward.
They allow users to collapse and expand both at the master level and for individual categories, support reordering (which is something we still need to work on), and use a flat search with breadcrumbs as well.
Wix.categories.mov
fcoveram commentedon Aug 10, 2026
Yep 🙂
Wix feels simpler, but I'd say that your proposal for breadcrumb in flat search feels cleaner. It scales better when texts are long.
annezazu commentedon Sep 6, 2026
@verofasulo when you have time, can you share an update here that clearly shows which option you explored has alignment from design that a dev can work on? Reading this over, it's not quite clear and I'd love to see if we can get dev help on this for 7.2.
verofasulo commentedon Sep 8, 2026
@annezazu sure thing! Here's where things landed after the discussion above.
Direction with design alignment
Nesting.mp4
Decisions taken on the open questions
@wordpress/admin-ui, in a smaller (12px /--wpds-typography-font-size-sm) and non-linked variant. That may need a small extension of the component.Still open (shouldn't block a first implementation)
@dinhtungdu @gigitux since you're picking this up, I'm available for any questions or to clarify anything that's unclear — feel free to ping me anytime. 🙂
dinhtungdu commentedon Oct 12, 2026
In the stack at #83315, I got the UI working as design: expansion, pagination, search are working. But there is a catch: the collectiton response categories or pages or any hierarchical data now doesn't have a property indicate an item has children or not, so:
Screen.Recording.2026-10-12.at.15.10.34.mov
To have real hierarchy, we will need to update the REST API collection response of hierarchical items like page or hierarchical taxonomies in Core. I think about
has_childrenvschild_count, but for collection data, we probably should just go with a boolhas_childrenfor scalability.Do you agree
has_childrenis a blocker or we should try shipping some other parts while working on adding that property? cc @verofasulo @oandregal @ntsekouras @gigituxgigitux commentedon Oct 12, 2026
I haven’t checked the code yet, but I think it makes sense to split the work.
DataViews is a generic library, so we can implement the hierarchical view independently, allowing consumers whose REST APIs already expose the necessary information to start using it. On the WordPress side, we’ll also need to update the REST API endpoint to expose that information.
With that in mind, I’d split the work into three parts:
has_childrenfield to the relevant endpoint.dinhtungdu commentedon Oct 12, 2026
Ah yes, it makes sense. The current stack is already support the first part.