ValueTree add/remove children in plural

So i’ve come to the struggle with performing actions on ValueTrees which involve adding or removing hundreds of nodes in a single action. The ValueTree is awesome and everything works peaches, but as each node correspond with a component in the UI, propagating the changes through the ValueTree observer system one by one is just too much overhead. Why isn’t there an addChildren and removeChildren -methods, that add/remove N nodes as a single update?

I’m sure many of you have been here. How do you manage such tasks? I find myself dismantling the whole observer tree and performing the changes with everything disconnected and then putting it all together triggering a single update that propagates all the changes at once and quite frankly i feel like an idiot doing so and the code isn’t pretty either. How are you dealing with this?

The problem isn’t so hard when making the initial changes e.g. deleting a bunch of nodes, but undoing them with the UndoManager is impossible without triggering a thousand separate updates.

The ValueTree change listener methods need to be kept as efficient as possible - then 1000’s of calls is not a problem. If any single change leads to a lot of work in the components/listeners, the logic needs to be refactored to perform the heavy operation later. I feed entire preset changes through single setProperty calls and if that doesn’t work, it points to either a bug or an operation that should be performed in a different way to not use as much time.

I agree 100%. What i was suggesting is that the ValueTree class should offer a way to combine massive amounts of updates into a single transaction with separate listener interface e.g. valueTreeChildrenAdded/valueTreeChildrenRemoved. Like you said, at the moment we need to implement such functionality on our own.

1 Like

Maybe you could solve this problem by grouping the ValueTrees better? Like, if you have to remove hundreds of ValueTrees of type “knob”, then maybe they should all be grouped together in a sub-node called “knobs”, and that way you only have to remove one.


That’s a great idea and would be very nice if it would suit my needs. Unfortunately my use case resembles more that of a user selecting an arbitrary range of items to be removed at once.

The disconnect/reconnect approach i mentioned can be achieved by first removing the parent node of the items, then remove the items from the parent node and finally restore i.e. add the parent node. The final add operation can be observed as a single update, but its not quite the same as add/remove children.