Tree-View Layout

[benhaynes]

If you have deeply nested (or self-nested) items, it would be nice to have a layout that let's you more efficiently browse, see, explore those items by expanding each item and seeing the children. In this way you could have a nice tree-view that async loads relational content.

I can build a design for this if someone's interested in taking it on!

Ref: https://github.com/directus/app/issues/1781

[danieljwestman]

This would indeed be sweet!

[Sennik]

I used this approach for years in my CMS (Which I love to replace with Directus).

It is IMHO necessary to have an option to create hierarchical content for a website to begin with. It is very usefull to create and maintain navigation without having to create them seperately and connect content to the nodes.

[rijkvanzanten]

It is IMHO necessary to have an option to create hierarchical content for a website to begin with

Directus does have full relational fields support already of course, this would just be an extra way to view nested data in a more hierarchical structure on the listing pages 🙂

[Sennik]

Indeed, but not only to view, but also to create and change I assume. I really think it would be a very helpful addition to the existing layouts. Usen tree view for webcontent (in menu structures), and table view for generic content like news, or projects or blogs, etc

[everyx]

@rijkvanzanten In tree view, if we want add the ability to change a node's depth, parent, and order(maybe drag and drop), we need to have a set rule of the data struct of the tree, something like this Nested set model, looking forward to this feature :)

[cupcakearmy]

Can second that, almost any website needs this. It's possible without it as @rijkvanzanten said but it would improve the product by a ton :)

[bcartier]

Would love to see this feature in the core product!

[eXaminator]

It feels like allowing a single collection to be nested and have an interactive tree view (just like we have table, cards etc. now) would probably help solve many use cases (the most common one would probably nested pages / website navigation).

[rijkvanzanten]

@eXaminator Website navigation is an interesting one though. Often times, you'd want to differentiate between menus and menu_items, in which case it's no longer a single recursive type 🤔

[LasseRosenow]

@rijkvanzanten Having TreeViews for more then just single type collections would be great 😀 I wrote down a Feature request as to how it could be achieved a while ago: #7447

(The technical details are within our conversation below the main post)

[eXaminator]

So my use case is specifically intended to be simple. I don't want menus and menu items. I just want pages. Root pages will be displayed in the main navigation, children in a second or third level navigation. If I wanted a deviation between menus and menu items, I could probably have a workaround using rules to change the relevant fields based on wether it's a root element or not. I think this could be a useful first step. Of course, allowing any kind of tree would be neat, but that could easily become a UX hell I guess...

[rijkvanzanten]

but that could easily become a UX hell I guess...

Haha yeah exactly! That's what I'm trying to think through here 🙂

[MMTHD]

"Upvote" for rethink the priority of implementation of this feature (from Q3 2022 to Q3 2021 :D)

[MMTHD]

My thoughts about the functionality of this is following:

• By creating a collection we should have a checkbox "Nested/Hierarchical", which creates automatically some fields which are necessary for that like child, parent, sort etc.
• In the frontend view, it should be the same table like now but the draggable option should be able to nesting items (https://sortablejs.github.io/Vue.Draggable/#/nested-with-vmodel)

I think the implementation should be simple, do i forgot some things?

[Sennik]

Exactly. Or simply drag an item a couple of mm to the right to 'create' the parent/child relationship, like Statamic offers. Statamic uses no database though (until you need one ;-))

[KrisKnez]

I think this is a great idea. We should have this!

[VaZark]

I’m not super well versed in db hierarchy logic but maybe we can take some inspiration from django-treebeard ?

[KrisKnez]

I'd like to note that the Tree-view layout is in the roadmap.

Hopefully, it is on schedule! 😄

[VaZark]

Sql views too!! That makes life so much easier when needing denormed data

[brett-james-rocketlab]

Is there any kind of inprogress screenshot if it's available, to give us an idea of how it's planned to look like? Also keen to make use of this request.

[cloudcompute]

Hello, Using this tree, would it be possible to see our website content in the form of a tree.. and the user would be able to edit the content of a particular node by clicking on it?

[valery]

Hi, Any progress to show for this so much needed feature?

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[rijkvanzanten]

New RFC based take on the same thing: #18651 🙂 (cc @w0kyj)

[w0kyj]

Adding RFC spec format and aggregated notes from other tickets:
Other related GH Discussions:
#7447
#18651

Summary

A tree view layout adds presentation as hierarchical list of deeply nested (or self-nested) items. The layout would allow the content user to more efficiently browse and manage parent child relational data.

Basic Examples

Tree views can be used to represent:

• hierarchical structure representing some engineering locations, called “functional locations”
  • each location may have sub-locations via recursive tree relationship

• parent/child pages
  • an item representing a web page with a recursive tree relationship may be expanded to show the related sub-pages
• project management displaying the tasks and recursive sub-tasks

Motivation

Improve user experience and understanding of Tree hierarchy fields within collections. Currently user can only view the trees hierarchy in the individual item form.

This is beneficial for a wide variety of use cases with hierarchical relationships including files/folders web pages, menus, project management, inventory, locations, etc

Detailed Design

Support relational type: tree view

• Allow manual sorting of tree items in the layout
  • needed on all displayed levels:

Column Sorting Examples

1. Initial table

Level0	Level1	Level2	Text	Number
A			Parent A	45
	AA		Child AA	42
		AAA	Sub-child AAA	154
		AAB	Sub-child AAB	11
	AB		Child AB	37
		ABA	Sub-child ABA	12
B			Parent B	99
	BA		Child BA	0

1. Hierarchy Column sorted descending by Level0

Level0	Level1	Level2	Text	Number
B			Parent B	99
	BA		Child BA	0
A			Parent A	45
	AA		Child AA	42
		AAA	Sub-child AAA	154
		AAB	Sub-child AAB	11
	AB		Child AB	37
		ABA	Sub-child ABA	12

1. Hierarchy Column sorted descending by Level1

Level0	Level1	Level2	Text	Number
A			Parent A	45
	AB		Child AB	37
		ABA	Sub-child ABA	12
	AA		Child AA	42
		AAA	Sub-child AAA	154
		AAB	Sub-child AAB	11
B			Parent B	99
	BA		Child BA	0

1. Non-Hierarchy Column sorted ascending

Level0	Level1	Level2	Text	Number
A			Parent A	45
	AB		Child AB	37
		ABA	Sub-child ABA	12
	AA		Child AA	42
		AAB	Sub-child AAB	11
		AAA	Sub-child AAA	154
B			Parent B	99
	BA		Child BA	0

Item Manual Sorting

1. Hierarchy Change by Level0

Manual Sort	Level0	Level1	Level2	Text	Number
==	B			Parent B	99
==		BA		Child BA	0
==	A			Parent A	45
==		AA		Child AA	42
==			AAA	Sub-child AAA	154
==			AAB	Sub-child AAB	11
==		AB		Child AB	37
==			ABA	Sub-child ABA	12

1. OPTIONAL: Child Hierarchy Changes (Level1+)

Manual Sort	Level0	Level1	Level2	Text	Number
==	A			Parent A	45
==		AB		Child AB	37
==			ABA	Sub-child ABA	12
==		AA		Child AA	42
==			AAA	Sub-child AAA	154
==			AAB	Sub-child AAB	11
==	B			Parent B	99
==		BA		Child BA	0

Manual Sort	Level0	Level1	Level2	Text	Number
==	A			Parent A	45
==		AA		Child AA	42
==			AAA	Sub-child AAA	154
==			AAB	Sub-child AAB	11
==	AB			Parent AB	37
==		ABA		Child ABA	12
==	B			Parent B	99
==		BA		Child BA	0

Changing Root Item Option

Requirements List

Must haves:

• Same features and capabilities of the current “Table” layout with added support for Tree View fields to show nested hierarchy of the children
  • Existing table layout + to add columns
    • NOTE: Parent and child have same columns for Tree View fields
  • In case ideas/rules needed for the tree views, resources:
    • Nested set model
    • https://github.com/django-treebeard/django-treebeard
    • In the frontend view, it should be the same table like now but the draggable option should be able to nesting items (https://sortablejs.github.io/Vue.Draggable/#/nested-with-vmodel)
  • Root Manual Sorting - Example above
• Column Sorting
  • All fields, but the hierarchy fields would be prioritized
    • Examples above
• Layout Configuration
  • Hierarchy Source Field
    • Only one hierarchy field at a time
    • Ideally this is a filtered list of valid relational fields (similar to Kanban configurations)

Should haves:

• If the tree is expanded and you click on any of the child items, then open the clicked item

Could haves:

• Tree View Fields
  • Manual Sorting for Child Hierarchy (Level1+)
    • Change parent, depth and/or order
    • Examples above
• Syncs opened hierarchies to local storage
  • App tries to return to same view when returning from item edits, etc.
• Some way to select/click/double-click child item and make it the new current root for deeper viewing
  • Similar to File Folder explorers on Operating Systems
  • Add example of MacOS file explorer - JONATHAN

Will not have:

• Support for other relational types: m2o to another table, m2m(translations), m2a, file, files, images

Drawbacks

Performance overhead for the table layout

Alternatives

Custom layout extension built by clients or partners.

Adoption Strategy

Augments existing layouts. Users may choose to use or not. All clients with recursive tree relationships will be able to visualize the parent-child relationships more easily.

Unresolved Questions

Additional Relationship Support Considerations

• Display of parent and child field(s) for other relationships (m2o, o2m, m2m(translations), m2a, file, files, images)
  • Only a single column -- use Collection Display for each level?
  • Single column -- layout configuration Display for each level (max number of levels)?
  • Multiple columns - if this, then need detailed requirements, considerations include
    • What if there are multiple relational fields?
    • What if the child has additional relational fields?
• How many levels should be allowed in the display?
  • Configurable in the layout configuration?
  • Env or Hard max limit?
  • If multiple columns, depth enforcement is different for children vs parents?
• App Queries & Caching
  • Starts closed for all root items - performance issues for any other alternatives
  • How much data should be fetched initially?
  • When to fetch child level data?
• Pagination
  • What happens when the child rows exceed the number of page rows?

[eXaminator]

I would like to propose a "could have", even though it might not strictly be part of the table view itself but also of other tree components: the ability to define a maximum depth (number of levels). Maybe this could be a feature of just the tree view, in that it would only show items up to a certain level and would only allow interaction with them.

Another "could have": allow the creation of a new child elements directly from a tree view, which would open the normal creation form but with a prepopulated parent field.

[rijkvanzanten]

I think that first could have is actually more of a must-have—or at least we need to have an upper limit to make sure we can keep the app performant

[formfcw]

I have created a design prototype for a tree structure where the main idea is to integrate the feature into the existing table layout rather than adding a new one. Have a look:

tree-view-layout.mp4

[formfcw]

Thank you, nice to hear!

[vitalijalbu]

hope we'll get it one day... 😁

[danieljwestman]

Is this something that is actively being worked on? Are you building this as extension @formfcw ? 🙌🏼

[formfcw]

Is this something that is actively being worked on? Are you building this as extension @formfcw ? 🙌🏼

No, I am not working on an extension.

[phil-sola]

Is this feature currently under development? I can see from the above screenshot of the roadmap it was on their in 2022 and looks like it's under 'next' on the current roadmap.

Tree view for hierarchical content under collections, is essential really for understanding at a quick glance the relationships between pages and etc.

I would love to see this get released!

[AAverin]

Not sure how related is it to this discussion, hope it is.
I have built a collection with Tree View setup, that is essentially a tree of nested categories. Tree is quite deep.
Now when I connect my categories as many-to-many relationship to a product table, I was expecting to see a tree-view there, but instead I see just a table that is very difficult to manage and work with.
Would this new "Tree View Layout" allow to better manage such nested collections? If yes, any update on the progress?

[u12206050]

Any update on this layout? Otherwise I'll be starting to create my own one today! :)

[madc]

Would love to support if you decide to build it publicly.