Events for node changed, children changed, tree changed

[jameswu1818]

Not sure if this the right channel to request features, but I think three events are missing:
when a node is changed
when children for a node is changed
when any tree node changed

Thanks for the awesome utility.

[mar10]

That would be a nice feature.

Currently all events are at tree-level, so I could only think of s.th. like a 'modify' event, that receives additional info like node, type (create, update, delete), and maybe additional data like a dict of modified field values.
Also, it would only catch changes that are generated by API functions like node.setTitle(), node.moveTo(), remove(), addChildren, etc.
A node.title = "x"; node.render(); would go unnoticed.
There would be potentially a lot of events, when the tree is initialised, or a lazy load requests returns, which could impact performance.

Can you provide some concrete use cases for your request?

[jameswu1818]

treeChangedEvent:
You are right, It would be too much to fire treeChangedEvent for each node change, it should be fired only on tree level functions.

Use Case1: Need to swap list of data set to display in a tree table. Base on selection, the corresponding set data is loaded in the tree. A column have buttons created in run time.Number or type of buttons are based on type of nodes. After tree is loaded, I want to bind click events of the buttons. treeChanged event would come in handy. Right now, I have to using setTimer() for it to work.

nodeChangedEvent:
User data change are more interesting for user, maybe provide a function just to fire an node change event? For example:
node.title='x';
node.data.myButtons=["Approve", "Reject"];
node.fireNodeChangedEvent();

UC2: When create or update a node, nodeChangedEvent would help to bind button events, as in use case above.
UC3: For display statistics of node type/status/...etc of a dynamic tree in real time, in a different panel.
UC4: Change correlated nodes automatically

childChangedEvent:
UC5: There are too many child nodes to show under a parent node. Want to make some paging mechanism to display only a portion of child nodes. childChangedEvent is helpful to manage the paging logic.

UC6: To show child count on a parent node

[mar10]

Thanks.
(Btw: i would advise against binding to separate elements. UC1 and UC2 could be solved better using event delegation.)

[jameswu1818]

Great. I'll read about how delegation works

[bpromasmb]

+1 to this. It would be useful to capture this moment. I would find this useful since I am needing to disable a button in my document whenever there is any change to the tree (in this case I am generating a spreadsheet from the created tree and want to prevent the user from exporting a tree before saving it to database)

[mar10]

Due to low priority and current lack of resources, this issue was tentatively put aside.
See also info about deferred issues.

[mar10]

As a first step we could implement a modifyChild event, which passes

• operation (remove, add, order, rename, data, ...)
• parent node (may be the invisible system root)
• modified node (only for rename and single node 'add' etc., but not always available)
• optional extra data (for example previous title?)

Since some operations (order, load) do not have one single meaningful context node, the event is fired for the parent nodes.

Fancytree could trigger this on

• node.addChildren() and related methods
• node.fromDict()
• node.load()
• node.moveTo() (either 'remove'+'add' or 'move', depending if parent node is identical)
• node.remove() and related methods
• node.setTitle()
• node.sortChildren() ?? only if order was really changed
• 'ext-edit' on save
• tree.applyPatch()
• tree.clear()
• tree.reload()

Also a method parentNode.triggerModify(operation, [node], [extra]) will allow to trigger this event if Fancytree is not aware of it, e.g. when node.data properties have been changed directly.

• Performance is an issue. We should not fire lots of events on load, for example
• The current event removeNode should be removed and replaced by modifyChild('remove')
• modify handler is a good place to call parentNode.sortChildren(), but this may fire modify('sort', ...)?