Gallery

The FWTreeView inherits from Y.Widget and uses Y.FlyweightTreeManager to handle the nodes. As the root, it simply provides the bounding and content boxes for the nodes, the actual handling of the tree is left to the Flyweight module.

A tree can be created by simply providing a `tree` configuration attribute to the constructor, describing the tree. Further nodes can be added dynamically as the branches expand. Each node description may contain the following properties:

• label: text or HTML markup to be shown in the tree node.
• expanded: Signals the children of this node should be visible. (true by default).
• children: an array containing further node descriptors.
• id: id to assign to the outer DOM element for this node.
• type: a reference to a subclass of Y.FWTreeNode or a string with the name of such a class, used to display this node.

It supports dynamic loading of nodes and node selection.
Versions after Nov 9th have WAI-ARIA roles and states and keyboard support. (the example won't show this, I'll update it as soon as the new build comes out).

Performance Data

I timed a few rendering tests using this TreeView and one based on all Widgets each augmented with WidgetParent and WidgetChild.

The test was simply building a tree with a certain depth and a certain number of children per node. That is why the resulting number of nodes are not round numbers as they are the consequence of adding all those nodes. I used FireFox at first, but with the Widget-based tree, it showed the "script is taking too long" message with less than a couple of hundred nodes. In Chrome I could go to almost 800 before any complaints so I ended up using Chrome for all tests.

With a Widget-based tree, it took 16.5 seconds to draw a tree with 781 nodes. The same tree took 1.2 seconds using the Flyweight TreeView (all averages of several runs). So, it is almost 14 times faster.

Then I wondered, how about memory consumption? With the Widget-based TreeView approach and 781 nodes, Chrome simply died when trying to take the heap snapshot while 10.4MB with this TreeView. So I made the tree one level shallower and with 156 nodes, The Widget-based TreeView took 49MB against 6MB with this version; less than one eighth the memory consumption.

The obvious difference is that with 156 nodes in a tree 3 levels deep, the Widget-based approach requires 156 Widgets, one for each tree-node plus one for the TreeView container. When using the Flyweight pattern you get just one Widget (the overall container for the TreeView) and only 3 tree-node instances, one for each level of depth. Of course, in both cases, the markup created is the same and in the flyweight TreeView, there is the tree configuration object, which is a passive object for data storage, no methods, no nothing in it.