Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Y.Tree: An awesome generic tree data structure #429
This is an import of the SmugMug Tree gallery module, a generic tree data structure that provides a fast and friendly API for working with hierarchical data (such as the items in a Menu, TreeView, or even a DOM node).
What it does
A tree has a root node, which may contain any number of child nodes, which may themselves contain child nodes, ad infinitum.
Child nodes (
Don't believe me? Here's a stress test that demonstrates the SmugMug TreeView gallery module (which uses
Why YUI needs it
Tree structures are inherently useful for representing many types of data that web developers work with frequently. YUI currently has components such as Model and ModelList that are good for working with flat lists, but these components are awkward to use and perform poorly when shoehorned into representing hierarchical data.
Some of the most obvious potential use cases for a tree structure would be a treeview widget or a hierarchical menu. Here are a few other possible use cases to spur your imagination:
Act now and get these extensions for free!
This pull request includes several
Also included is a plugin,
@rgrove I think this component will be really useful, and it makes sense to me to have a YUI component which represents a standard data structure.
Beyond the comments I made inline, I have some other higher level comments:
Adds 9 New Modules
This component adds 9 new YUI modules, and I think it should be reduced down to 4. There is a pattern of
Here's how I would imagine organizing this component into modules:
This component uses two inheritance mechanisms: the standard
I would like use to see if we can avoid having to do that, and instead use
This is not currently feasible. If Base were performant enough for this use case, I'd have used it. If it were possible to use only part of it and get the performance I needed, I'd have used it. But I wasn't going to rearchitect Base just to meet the needs of Tree.Node.
The very simple class extension mechanism in Tree is essentially an extraction of the most fundamental concept of Base, but other than sharing a similar core concept, there's little relation between the two. This extension mechanism amounts to just a handful of code and allows Tree.Node to be extensible without becoming a heavyweight Base instance (and without waiting months or years for Base to be rearchitected).
If you're suggesting that we should extract this extension mechanism from Tree and make it generally available as a lightweight alternative to Base, I'd support that. But if you're suggesting that we add this use case to the long and ever-growing Base todo list, I'm not confident it will happen in a reasonable time frame, and I can't wait for it.
Yeah I get that (note the quote of myself above yours here), I wasn't suggesting that Tree.Node should extend Base.
I'm suggesting the something closer to the former. With the idea that it would sit along side
+1 to that, and I'd be willing to work on it. I don't want this to hold up Y.Tree though, since that's a whole new can of worms.
Sounds good. Knowing this is a future thing we expect to do, we'll want to make sure the extension mechanism in Tree isn't too specific that it can be refactored to use the generic utility in the future.
I don't see any reason for
I'm leaving for a vacation today so I may be slow in responding to further comments, but keep 'em coming.
On Thursday, February 14, 2013 at 8:30 AM, Juan Ignacio Dopazo wrote:
@ericf I took a pass at implementing