Friday, June 20th, 2008

jsTree: jQuery-based JavaScript tree component

Category: Ajax, Component, JavaScript

Ivan Bozhanov walked us through his jQuery-based tree component recently. The state of trees out there is interesting. YUI! has a nice, stable tree control but Dojo’s once feature-rich tree has been replaced with a fairly basic tree (i.e., doesn’t appear to have in-line editing and drag-and-drop still seems flakey; Dojo guys, correct me if I’m wrong) at the moment and jQuery UI lacks an official tree component (though a few tree plug-ins are out there); as you might expect, Ext JS has a nice tree component.

Let me highlight a few areas where jsTree stands out. First, it has some basic features that many trees out there lack:

jsTree allows the user to create, rename, reorder, move, and delete note (which is realised in a file-browser manner – eg. inplace)

It also has a rich event API which is fairly standard across most editable tree components, though the event types are finer-grained than in most trees I’ve seen (not sure whether that’s a good thing):

You can attach callbacks to almost every action:
– onbeforechange
– onchange
– onrename
– onmove
– oncreate
– ondelete
– onopen
– onclose

It also allows you to provide rules that govern what the user may or may not do based on the “type” of a node:

jsTree lets developers define rules for moving, selecting, deleting, and focusing nodes. The rules are based on developer-definable types of each node passed in the data (different sources define it differently). This limits the user in his actions. The developer can also attach inline rules which override global rules. One scenario in which these rules are useful is when you build a CMS and need a fixed number of top level nodes because of a design restriction.

While you could accomplish the same functionality with event handlers, it’s nice to have a simple built-in scheme that can be easily data-driven.

These rules are applied real-time as the user attempts to interact with the tree:

When you drag a node around a pointer tells you where you are about to insert it, and prevents the user from dropping anywhere against the rules. The warning is real time – as you drag and drop the pointer is replaced by a red cross if the action is against the defined rules. I’m still working on displaying definable text messages.

jsTree can be configured to reference a custom property in each node object to determine its type.

It also has built-in localization support; you specify string identifiers corresponding to the different languages that the tree should support on construction:


  1. tree1.init($("#nested"), {
  2.     data : "nested.xml",
  3.     xsl : "nested.xsl",
  4.     languages :  [ "en", "bg" ],
  5.     // other stuff omitted
  6. });

and then in this case each node in the XML tree fed to the component specifies its language:

  1. <name lang="bg" icon="images/f.png">Начало</name>
  2. <name lang="en" icon="images/f.png">Home</name>

In addition to XML data types, it also supports JSON and in-line HTML. But it also has built-in support for doing XSL transforms on XML data sources, including a scheme that lets you include flat data that it then makes into a hierarchy:

jsTree supports XSL transformations when using the XML data source option. This is a bit faster than javascript parsing. It includes an XSL stylesheet for transforming a flat list of entries into a tree. This can be useful if you use adjacency for maintaing a tree in a database. In such situations it is quite heavy on the server to dump the whole tree as you need N-1 queries where N is the number of nodes in the tree. With this XSL solution you can just dump the table flat out with id and parent_id attributes and the XSL will transform it into a nested structure.

Unfortunately, what jsTree is lacking is the visual refinement of many of the trees out there, but as jsTree is built on top of jQuery, we suppose Ivan can add that kind of polish easily.

For many data-driven applications, high-quality grid and tree components are really important; kudos to Ivan for some interesting ideas in jsTree. The docs are certainly better than some I’ve seen, but not as complete as I’d like.

Posted by Ben Galbraith at 5:00 am

3.9 rating from 136 votes


Comments feed TrackBack URI

Err, link?

Comment by maccmania — June 20, 2008

That would probably be: Google Code page and the Examples page

Comment by mauricesnip — June 20, 2008

neat! I like it. It certainly beats my implementation of jquery tree…

Comment by OndraM — June 20, 2008

Nice work. I agree that some graphic and interaction design would improve it a bit. I had written a UX design pattern for trees a while back. Maybe it’s helpful?

One minor thing would be to animate the open/close of the nodes. Its a small but significant aspect that would improve the general feel. I wonder also if there are royalty free open/close icons around.

Comment by GlenLipka — June 20, 2008

Thanks, this is indeed useful! I will go over the points this evening and also add the option for smooth animation.

Comment by vakata — June 20, 2008

The links to the examples in the documentation are bad.

I don’t see any mention of getting data from the server. I assume that’s left as an exercise for the user? The callbacks are the way to do that?

Comment by Nosredna — June 20, 2008

I feel that animations in tree’s are quite annoying. Thank god that Windows or Mac OS X don’t use animations in their tree’s.

Comment by Jeria — June 20, 2008

Sorry for the documentation – I plan on polishing it and giving some more examples very soon. Yes, the callbacks are the way to get data from the server – the example will be up soon (basically you pass the state parameter “closed”, and use the onopen callback). I intend on implementing async loading internally.

The next minor version will feature animations (thanks jQuery), but they will be optional/configurable.

Comment by vakata — June 20, 2008

@vakata: Great job, Ivan! Your jsTree is most probably the best web tree component I’ve seen to date!

Comment by kolev — June 20, 2008

Since I got a few emails complaining there is no way for people to contact me I put up a blog where everyone can comment, criticize and propose new ideas.

Comment by vakata — June 21, 2008

you’re right about Dojo’s tree WRT DnD and editing (although many people are successfully adding editing through the hooks we already provide in the Tree). What we’ve focused on is accessibility and backing which has allowed the Dojo Tree widget to handle lazy-loading of data, editing, gigantic data sets, and the ability to be constructed out of nearly any data format: pure HTML, CSV, XML, web services, JSON, lazy-loaded versions of many of the above, and more. All through the same APIs and data formats which are used to feed drop-down widgets, grids, and many other Dijit and DojoX widgets. I won’t really touch accessibility, but needless to say it’s non-trivial to do right. We look forward to a day when others consider a widget “done” only when it provides a good user experience to *everyone* and not before that.


Comment by slightlyoff — June 21, 2008

Leave a comment

You must be logged in to post a comment.