No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Issue with selection in large TreeGrid data (with nested children)


    I am struggling with the following issue. I will be happy if someone can suggest any idea to solve this performance problem.

    With the following piece of code, you will get a TreeGrid with columns. (screenshot attached).

    The performance issues starting when the tree includes 3 or more nested children combined with large piece of data.
    (Large data for example is when the root containes at least 5 children which each one of them containes at least 5000 children which containes more children).

    After the data got rendered, selecting one of the rows (main or nested), freezes the UI for a few seconds.

    In my case, the desired root data will contain dozens / hundreds rows with 3 or more children levels, in total ~50K rows.

    (When using 2 or less nested children - there are no visual performance issues. You can try it if you delete all the children property in the second loop).

    var tree = isc.Tree.create({
            modelType: "children",
            childrenProperty: "children",
            nameProperty: "Name",
            root: newData
          var myTreeGrid = isc.TreeGrid.create({
            ID: "TreeGrid",
            data: tree,
            height: 500,
            width: 1000,
            fields: [
              { name: "Name" },
              { name: "nodeType" },
              { name: "nodeTypeText" },
              { name: "nodeTitle" },
              { name: "detailsText" },
              { name: "detailsTextForPrint" },
              { name: "productId" },
              { name: "amountToPay" },
              { name: "itemOrPriceModifierId" },
              { name: "itemDetails" }
          for (var i = 0; i < 5; i++) {
            var newData = {
              EmployeeId: "new",
              Name: "new " + i,
              children: [{}]
            for (var j = 0; j < 10000; j++) {
                Name: "ch" + i + " " + j,
                nodeType: "2",
                nodeTypeText: "Payment" + i + " " + j,
                nodeTitle: "nodeTitle" + i + " " + j,
                detailsText: "QQQ" + i + " " + j,
                detailsTextForPrint: "EmployeeId" + Math.random(),
                productId: Math.random(),
                amountToPay: Math.random(),
                itemOrPriceModifierId: Math.random(),
                itemDetails: "EmployeeId" + i + " " + j,
                isFolder: true,
                parent: newData,
                children: [
                    Name: "www",
                    nodeTypeText: "www",
                    children: [
                        Name: "eee",
                        nodeTypeText: "eee",
                        children: [
                            Name: "ttt",
                            nodeTypeText: "ttt"

    Performance of selection is generally going to be related to the number of visible nodes, no matter the size of the tree.

    It looks like after populating the tree with data, you must be opening *a lot* of folders, probably programmatically, as it would take a very long time otherwise.

    It doesn't seem realistic to simulate a situation that would take an end user 30-40 minutes of clicking to create, as well as make a tree so vast it would be impossible to navigate effectively.


      Hi, tnx for your answer.

      I just want to make sure you understand the issue..
      The problem is the Selection (not creation) of one of the rows after the data is ready. (The code in the first post is just a simple way to create a large tree data).

      As I mentiond before, this issue occurs with large data + tree which have 3+ levels.
      Otherwise, even with ~100K rows in flat tree performance are fine.

      The end user will not create such data.
      I recieve such data set as a snapshot to work with it.

      The thing here is the 'Selection'.
      There is a performance problem with selction on structures as I explained.

      Is a fix for this issue is something u will can take in account for future versions?

      tnx again,


        Please re-read our response. We're talking about which folders are open hence how many are *visible*. We are not talking about how many are loaded.