Clarity: Dynamic tree view given a data model, allowing recursivity

[bertofer]

Select one ...

[ ] bug
[ ] feature request
[X] enhancement

Expected behavior

The tree view would allow the user to pass a recursive data model that gets rendered as a tree automatically, without having to create nested clr-tree-node manually.

There are a lot of situations where the tree does not have a prior known depth. Also, I think in a lot of scenarios, the normal content of a tree node will be a clr-icon, a text or a link, and then children if they exist.

What I am thinking of is an API similar to (angular2-tree-component)[https://angular2-tree.readme.io/docs].

Actual behavior

I tried to have my custom component as a wrapper for the clr-tree-node, like in this plunker:

https://plnkr.co/edit/tAgxHw

But in the current implementation, the children is got by @ContentChildren(TreeNode), and having a custom component as wrapper makes the nodes don't see each other with depth, which breaks the functionality of collapse and expand.

I could solve the problem in my current project by inheriting from the TreeNode and implementing the recursivity myself, in this component. Of course this is not a final solution at all, as it is a bit coupled to how my app works (e.g. icons are folders all the time, no dynamically passed), but I hope serves as an example of the functionality I would like to have and for others in the same situation.

I would be kind to help on the PR of this, after agreeing on a suitable API for all situations.

Environment details

• Angular version: 2.4.5

• Clarity version: 0.8.6

• OS and version: MacOS X 10.12.3

• Browser: [all]

[youdz]

Also, I think in a lot of scenarios, the normal content of a tree node will be a clr-icon, a text or a link, and then children if they exist.

That's our main problem here. Everyone has different expectation for the "normal" content of a tree node, or of a datagrid, or of a dialog. This is the reason we're going for a declarative API for all our components, simply projecting content and stamping templates you give us. Any API that uses one big JSON object on a single element and creates the whole view is too strict, we can't possibly keep up with the feature requests it would lead too (which would be blocking, something else we try to avoid).

Now, we understand the need for "recursive" treeviews, where you don't know the depth in advance. That's a very valid use case we want to support. Our recommendation on this is simply to create a custom recursive component using <clr-tree-node>, just like you did. I do not foresee this changing in the near future, unless we get many feature requests for the _exact_ same default node template from everyone.
@ContentChildren limitations do pose a few problems so you need a bit of extra wiring in there, but we're working right now on getting rid of this. In the meantime, the trick is simply to:
1) manually handle the expandable property, by putting [clrTreeNodeExpandable]="node.children" on your <clr-tree-node>
2) Project your component as a <clr-tree-node>, to make sure it ends up in the right place, by using ngProjectAs="clr-tree-node" on it.

I updated your plunker to show this in action: https://plnkr.co/edit/J7xXpi?p=preview
So you were almost there. 😄

For people who want a minimal example, I made a slightly simplified plunker: https://plnkr.co/edit/DXvPJgHB7yWFNnWuQjXA?p=preview

To sum up: we're currently investigating ways to make these two "hacks" unneeded, or at least one of them. In the meantime, go ahead and use them as a workaround, it should be safe.

[bertofer]

Ok @youdz thanks for your thorough answer!

I didn't know about the ngProjectAs, good one 😃

I leave you to close this if you consider, or leave it open / edit to keep it for the solutions / discussion for this hacky aproaches.

[Jinnie]

Hi all, @youdz ,
I'd like to 👍 this issue, as I had a similar problem recently, and @bertofer pointed me to this topic (thanks!)
After a little research, it seems that ngProjectAs is an undocumented angular feature. I myself am a little cautious using such features, as they may disappear any time. It's like using some private API 😨.
So, if you decide to go on and find the way to drop the "hacks" that'd be great, IMO.

[youdz]

To be honest, it's undocumented because the whole content projection part of Angular is undocumented. 😛 They have various issues open for that already, but here is the one on ngProjectAs: https://github.com/angular/angular.io/issues/1683

So you're pretty safe using it. 😉

I also want to note that from what I quickly researched at the time, ngProjectAs has a good chance of being the clean and correct solution for writing wrappers around projected content when using component libraries. The hack we really want to get rid of is the first one, which comes from @ContentChildren not working in that case. If we somehow find a solution that doesn't involve ngProjectAs, that'd be perfect, but we probably won't go too much of our way to make it happen.

[JhonePartooo]

there have other problem, when i try to implement recursive tree view with selection (Checkbox Tree).
it not work correctly, i attached plunker link
https://plnkr.co/edit/ERk8JE?p=preview

@youdz , maybe do you have any solution ?

[Jinnie]

+1
A more detailed plunker, which I used to reproduce it:
https://plnkr.co/edit/1Og6dT?p=preview

[Radu-Dunarentu]

@lidoravitan Hei, you managed to find a work around or the fix? I have the same problem when trying to created a tree with ngFor,
<clr-tree [(clrTreeSelected)]="selection"> <clr-tree-node *ngFor="let l1 of selection" [clrTreeModel]="l1.model"> {{l1.model}} <clr-tree-node *ngFor="let l2 of l1.children" [clrTreeModel]="l2.model"> {{l2.model}} <clr-tree-node *ngFor="let l3 of l2.children" [clrTreeModel]="l3.model"> {{l3.model}} </clr-tree-node> </clr-tree-node> </clr-tree-node> </clr-tree>

[JhonePartooo]

yes but I don't have a solution
Please update me
Thank you

בתאריך יום ו׳, 5 במאי 2017 ב-11:37 מאת Radu-Dunarentu <
[email protected]>:

@lidoravitan https://github.com/lidoravitan Hei, you managed to find a
work around or the fix? I have the same problem when trying to created a
tree with ngFor,
{{l1.model}} *ngFor="let l2 of l1.children" [clrTreeModel]="l2.model"> {{l2.model}}

{{l3.model}}

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/vmware/clarity/issues/487#issuecomment-299411611, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJrSMUDXUJGM2IDIdZndZU_yyDeuMwTrks5r2t-ygaJpZM4MAXMF
.

[adityarb88]

@bertofer We release 0.10.0-alpha which fixes this issue. Please see the 0.10.0-alpha release notes: https://vmware.github.io/clarity/news/0.10.0-alpha for more details.

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.