How to change the behavior of click on node (v3.0.4)

[monfortm]

Hello,

I am using v3.0.4 (I have yet to move to v3.0.5 after your last push). FYI: The tree construction works flawlessly, also with async root and nodes loading. FYI again - because I've read it in another issue #260 - I also managed to tweak parent/children checkbox behavior. To control the parent checkbox: Since my nodes are loaded asynchronously, I inject the parent node model as a property on the async loaded node (parent model available as a parameter), then I am able to do target.parent.treeNodeSpec.state.input.value = false to deselect the parent when I am checking the child.

Now the issue/question:

I am wondering if it is possible to modify the behavior of the click on nodes. The default is to select the node, but I personally don't need nodes to be "selectable" - I just need my nodes to be checkable and expandable, therefore I'd like to

• check the node when clicking the checkbox (default behavior, works well)
• expand it when clicking the node (that is, basically, spreading the expand behavior that exist on the "+/-" expand button to the whole node except the checkbox.

Using scoped slots and the injected { model } prop, I can easily toggle the node (model.treeNodeSpec.state.expanded = !model.treeNodeSpec.state.expanded), however my nodes rely on loadChildrenAsync to load their content. I tried model[model.treeNodeSpec.childrenProperty] = model.treeNodeSpec.loadChildrenAsync(model) without success.

Maybe its already doable but I don't quite get how? Also maybe the main behavioral functions (select, check, expand) could be available as properties on slots, a bit on the fashion of checkboxChangeHandler

Let me know if this makes any sense for you,

Thanks a lot,
Cheers,
M

[monfortm]

Another use case I see for exposing the load children async handler is to be able to re-trigger the loading when we know the response should be different (e.g. when a tree represents a file system and someone drops a file somewhere in the tree (server side) and we want the UI to be updated)

[grapoza]

Hey, sorry I've taken a bit to get back to you on this. I have a couple of ideas, but I haven't had a chance to test them out and make a codepen or anything. I probably won't get to that until after work tonight though, so I'll give you my thoughts so you at least may have a starting point.

The tree uses an internal property on the model, model.treeNodeSpec._.state.areChildrenLoaded to determine the loading state for the child nodes. To re-trigger the async load, I think you'd need to:

1. set the node's expanded property to false
2. set the children list to [] (probably not necessary, but why not clean up after ourselves)
3. set the internal model.treeNodeSpec._.state.areChildrenLoaded property to false
4. set the node's expanded property to true again to re-trigger the async load

Again, I haven't had a chance to test it out, but I'm pretty sure that will work.

[monfortm]

Hello, really no problem for the delay, I am not expecting immediate answers.

What you describe makes sense, I'll try doing that! It's not so much of an issue except for the toggling expanded which I assume will look weird interms of ui/ux! But if it works, it works!

I would still be in favor of an exposed (re)loadChildren handler. Maybe not in this old version but in the newer one.

Cheers!
M

[grapoza]

I agree, the ability to reload async children has some convincing use cases. I've added #279 to capture this for inclusion in 5.1.0. I doubt it will be difficult to add. Thanks for the suggestion! I'll leave this issue open so you can let me know if the proposed solution above (or some variation) works for you, or if we need to work together a little more to get what you need.

[monfortm]

Hello @grapoza, so, coming back to it: Step 4 does not work as expected. The node is expanded and empty but this does not trigger the load children request (the request does not appear in the network tab!). Any idea of something else that should be toggle to trigger the request ?

[grapoza]

Alright, I finally got to sit down and pen this out. I think the expander behavior is one of those things that's just been around since day one and got beaten around and ignored over time to the point where even I forgot how it actually works. Turns out the behavior isn't a watch on expanded like I assumed, it's actually done through a couple of event handlers. I made a pen with a working (but so ugly) block of code, which links to the handlers to further clarify. Let me know if this is helpful.

https://codesandbox.io/s/exciting-lichterman-5dfmjq?file=/src/App.vue

[monfortm]

Hello,

So it's indeed a bit hacky but it works as expected! This issue is solved, feel free to close it.

I'm currently developing a feature using this tree and I will have additional question. Let me know if I should ask them here or open other issues.

For example: I tried to initialise a node as expanded, but I could not. I tried to set expandable: true and state: {expanded: true} on the node model, but could not manage. Is is supposed to work as is, even in case node children are async loaded or the expanded behavior works only on sync node/static tree

Cheers

[grapoza]

Yeah, let's document the issues separately, that way I can keep track of which I would just add to 5.x and which I would add to both 5.x and 3.x.

For the expanded async children, it looks like there's no handling for expanded children with their own async children (though there should be). That should go in as an issue. If you'd be good enough to enter the issue for me, I'll let you decide if you want it for 3.x as a thank you for finding these cases for me. :)

An alternative fix in the meantime would be similar to the hack you used above, where you could handle the treeViewNodeChildrenLoad event and collapse/expand the children that need the async loader to fire for their own children.

[monfortm]

Okay, I am opening new issues!