lazy loading 2000+ nodes in jstree

3,262 views
Skip to first unread message

evolye wang

unread,
Jan 22, 2010, 9:55:36 PM1/22/10
to jsTree
Hi all , our client has a requirement needs to represent 2000 nodes in
a tree. I implement the background logic with java , first construct
the model l in memory and then serialize it to json.
The recursive algorithm needs to reach 6 level deep . After
serializing to json , I passed the json literal to Jstree . I guess ,
Jstree will parse the large bulk of json string and generate out the
corresponding html , however this process is extremely slow. It needs
nearly 20-30s to complete this ,and the Jstree is occasionally freeze
or unable to expand the nodes.

I guess this is a wrong approach to do this job. So I have 2
questions .

1. If I use java directly generate the html as Jstree data source ,
does this theoretically 2 times faster than json , because it doesn't
need to parse jason to html ?
2. Does Jstree has a build in support for lazy loading ? that's to
say , when I click the "+" to expand the children nodes , jstree will
load next level data . well this event is easy to capture , but how
can I pass the next level data to it's parent node without the whole
tree be refreshed ?

John Arrowwood

unread,
Jan 22, 2010, 10:16:04 PM1/22/10
to jst...@googlegroups.com
Is the Java on the server side, or on the client side?

Assuming it is on the server side, yes, the fastest approach will be to generate HTML directly in the Java code. 

And yes, you can do lazy loading.  When the tree needs to load the full tree, it will contact the server with a parameter of 'id' with a value of 0.  The server side code needs to return only those nodes that are visible.  When it needs a child node, it will give the ID value of that node whose children need to be fetched.  Realize, you must set the ID of a node ( <li id='foo'> ) in order for that to work.

So, it would first return the root nodes.  If a root node is open, then it would return that node's children as part of the return.  For those that are closed, it would not include a nested <ul> tag, and it would give the <li> of the node a class of 'closed'.  For nodes that have no children, it would give the class 'leaf'. 

If you are not sure, just take the code that you have, slow though it may be, generate the tree, then inspect it using firebug.  It'll be clear what you need to generate.



--
You received this message because you are subscribed to the Google Groups "jsTree" group.
To post to this group, send email to jst...@googlegroups.com.
To unsubscribe from this group, send email to jstree+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jstree?hl=en.




--
John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com
--
http://www.irie-inc.com/
http://arrowwood.blogspot.com/

evolye wang

unread,
Jan 23, 2010, 10:24:10 AM1/23/10
to jsTree
Thanks John , it's very nice of to answer my questions.

I know Jstree has the ability to lazily load data when expand the
node. But I could only set the data store once when the tree is setup.
How can I pass the lazily loaded html to the current expanded node as
it's children ? Fetching the data is no problem. I don't know how to
set the children nodes to it's parent. I guess it isn't done with
jquery's api by injecting children html to parent <li> tag.

> > jstree+un...@googlegroups.com<jstree%2Bunsu...@googlegroups.com>

John Arrowwood

unread,
Jan 23, 2010, 10:48:13 AM1/23/10
to jst...@googlegroups.com
You don't have to inject anything.  If you set up the tree correctly, and it is fetching the data from the server, the tree injects the nodes itself.

To unsubscribe from this group, send email to jstree+un...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/jstree?hl=en.




--
John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com

Bernard Bernard

unread,
Jan 23, 2010, 2:09:30 PM1/23/10
to jst...@googlegroups.com
I think your requirements will be addressed with features in the new release.

See

http://code.google.com/p/jstree/issues/detail?id=332

Personally, I would not try to build a model in HTML.

Stéphane

unread,
Jan 26, 2010, 5:12:01 AM1/26/10
to jsTree

@John Arrowwood

I used this approach before generating the html "ul li" and adding the
jstree on top of that to make it a treeview. What happened is that the
list of uls li first displayed on the page without being parsed by
jstree because jstree was too slow parsing it. in the case of 2000++
nodes, i would guess that you would see that ul li list for about 20
seconds before it becomes a treeview. I used asynchronous load and it
went much faster in my case.
When applying jstree to an existing html, jstree needs to select every
html node and add classes to it. Correct me if I'm wrong, but I doubt
this is faster than generating the html from a json object.
Vakata could probably answer this better :).
Please tell us how it goes Evloye Wang. Interesting to know how you
solve your problem.
Also the version 1.0 is announced to be *much* faster, so that might
solve some of your problem too.

Stéphane

> > jstree+un...@googlegroups.com<jstree%2Bunsu...@googlegroups.com>

Chrazy

unread,
Jan 26, 2010, 5:59:18 AM1/26/10
to jsTree
The time it takes, did you see if it was the parsing that took time or
if it was your Java that took time? Using Lotus Notes, I tried to
display a tree with 1000+ nodes that was generated from JSON and was
parsed in about 2 seconds. Sounds like something fishy.

John Arrowwood

unread,
Jan 26, 2010, 10:44:28 AM1/26/10
to jst...@googlegroups.com
On Tue, Jan 26, 2010 at 2:12 AM, Stéphane <stephane...@gmail.com> wrote:

@John Arrowwood

I used this approach before generating the html "ul li" and adding the
jstree on top of that to make it a treeview. What happened is that the
list of uls li first displayed on the page without being parsed by
jstree because jstree was too slow parsing it. in the case of 2000++
nodes, i would guess that you would see that ul li list for about 20
seconds before it becomes a treeview.

Correct.  Best to hide the list while it is loading.
 
I used asynchronous load and it
went much faster in my case.
When applying jstree to an existing html, jstree needs to select every
html node and add classes to it. Correct me if I'm wrong, but I doubt
this is faster than generating the html from a json object.

Which is faster?  I've not done a comparison, but I have looked at the code, and I have read this list, and based on what I have seen, HTML is faster than JSON.  But if you want to get the maximum performance out of it, then you want to implement it in different ways, and see which is faster.  And don't forget to test it on different browsers, because performance will vary from browser to browser.

From the perspective of the end user, though, the load-as-you-go approach will be best, unless you have a flat tree with 2000+ nodes, in which case why use a tree?  :)
 
To unsubscribe from this group, send email to jstree+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jstree?hl=en.

Stéphane

unread,
Feb 1, 2010, 5:09:19 AM2/1/10
to jsTree
using html, i think what was slow is that the browser first had to
render the lis, and then jstree would take over, transform it and
browser renders it again
(since I didnt hide it at first)...

html >> render >> jquery select >> change classes >> render again //
so I guess if you hide it first, it's faster, since you skip the first
rendering :)
json >> generate html >> inject >> render

I didnt try just to hide it first, I went for the json solution, and
it was just perfect...
On my developer machine, html solution was fine and fast, but I saw it
rendering very slow on a slower machine.
Anyway, we're going to upgrade it to 1.0 using jquery 1.4 anytime soon
I am guessing, so i can test that then :)'

Thanks for your input

On Jan 26, 4:44 pm, John Arrowwood <jarro...@gmail.com> wrote:

> > <jstree%2Bunsu...@googlegroups.com<jstree%252Buns...@googlegroups.com>


>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/jstree?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jsTree" group.
> > To post to this group, send email to jst...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jstree+un...@googlegroups.com<jstree%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jstree?hl=en.
>
> --

vakata

unread,
Feb 3, 2010, 9:10:15 AM2/3/10
to jsTree
Well I have not tested 1.0 xml yet, but in previous versions XML was
the fastest datastore of all (as it uses XSLT internally and did not
need a cleanup of the nodes afterwards). I will test with the new
version and let you know. (my test was a 800 node nested tree, which
rendered from XML with practically now delay)

Cheers,
Ivan

ducle

unread,
Feb 3, 2010, 9:53:21 AM2/3/10
to jsTree
I have tree with 3500+ nodes, and will try with xml datastore as you
suggested, Ivan. With html it takes 2-3 min to display tree with all
nodes, what is so slow.
@John: : which structure did you want to suggest for so high amount of
nodes?

Jesse

unread,
Feb 3, 2010, 12:28:44 PM2/3/10
to jsTree
2-3 minutes!!! thats insane..

one of our clients has a node structure with 11,000 (yes eleven
thousand) nodes.. im spitting out html straight to the client through
a recursive loop (its a nested set structure) .. data is processed
and displayed on the clients machine in 5 seconds flat.

J

vakata

unread,
Feb 4, 2010, 9:29:49 AM2/4/10
to jsTree
Actually the best way to go is indeed async loading (on-demand if you
will). I guess there are extremely rare cases where the user would
require all thousands of nodes to be accessible at the same time.
Usually on-demand loading works best both for the client and the
server.
As for the XML datastore - in 1.0 it introduces a config option called
clean_node, which defaults to false. This is because I have tried to
output clean HTML in the required structure. This means no traversing
and adding classes, so it should be as fast as the browser itself.

Kindest regards,
Ivan

Reply all
Reply to author
Forward
0 new messages