2

i have a javascript array of objects with objects that look like this:

itemId
name
parentItemId <== top level items with no parent have null value

I want to build a graph where the parent items contain arrays of children and those children have arrays of children if applicable.

What is a good way to go about this?

Joseph Marikle
  • 76,418
  • 17
  • 112
  • 129
billy jean
  • 1,399
  • 4
  • 25
  • 45

3 Answers3

5
function objectGraph(items)
{
    var items_by_id = {};
    var roots = [];
    var i;

    // Build an id->object mapping, so we don't have to go hunting for parents
    for (i = 0; i < items.length; ++i) {
        items_by_id[items[i].itemId] = items[i];
        items[i].children = [];
    }

    for (i = 0; i < items.length; ++i) {
        var parentId = items[i].parentItemId;
        // If parentId is null, this is a root; otherwise, it's parentId's kid
        var nodes = (parentId === null) ? roots : items_by_id[parentId].children;
        nodes.push(items[i]);
    }
    return roots;
}

Note, this code gives every node a children property, that's empty if a node has no kids. I personally find it simpler and more consistent than each node maybe-or-maybe-not having children; you can loop over children without worrying whether it exists. A leaf node will have children.length == 0.

If you can guarantee you have exactly one root, you can return roots[0]; instead of returning the array.

cHao
  • 84,970
  • 20
  • 145
  • 172
  • so instead of doing if(children) you do if(children.length == 0)...hmm I guess that has its use if you want to blanket iterate the items and then decide if its a leaf or not. I usually do it the other way round. – James Sep 13 '11 at 22:37
  • Instead of doing `if (children)`, you'd do `if (children.length)`. Either way can work OK (checking for the list's existence vs whether it contains anything), but the latter means less special-casing and less having to worry about whether you'll get undefined-object errors. If you want, you can treat a leaf node like any other, and iterate over its kids; you just won't have any kids to do anything with. :) Note that the DOM works similarly; every node has a list of children, even if that list is empty. – cHao Sep 13 '11 at 22:46
  • True enough and also firefox (probably all browsers) return 0 for children.length of an empty DOM element. Also my solution does the same thing lol. – James Sep 13 '11 at 22:57
  • +1 This solution is the way to go, thanks for the lesson cHao. I now have a few changes to make in some of my own code :) – James Sep 13 '11 at 23:18
  • I'll give my props here to this. It only loops through the whole array twice, where as the recursive options we've come up with will loop through the entire array on each recursive call. Clever work! I would suggest maybe caching the `.length` property of the array in a variable as in some browsers it can speed up the loop. – ericb Sep 14 '11 at 13:32
0

This is a little rough, but it should do the job if I'm gathering your question correctly. It should return an array of top level objects that have their children correctly organized below them.

As a note, this will work for an N-level of children objects, and not just a single level.

var finalArray = [];
var YOUR_RAW_ARRAY = [];

var buildObjectGraph = function(inputArray){
    var i = 0, len = inputArray.length;
    var returnVal = [];

    for(;i<len;i++){
        if(inputArray[i].parentItemId === null){
            findChildren(inputArray[i], inputArray);
            returnVal.push(inputArray[i]);
        }
    }

    var findChildren = function(root){
        var i = 0, i2 = 0, len = rawDataArray.length, len2 = 0;

        for(;i<len;i++){
            if(inputArray[i].parentItemId === root.itemId){
                if(root.children){
                    root.children.push(inputArray[i]);
                }else{
                    root.children = [];
                    root.children.push(inputArray[i]);
                }
            }
        }

        //now call it recursively
        len2 = root.children.length;
        if(len2 > 0){
            for(;i2 < len2; i2++){
                findChildren(root.children[i2]);
            }
        }
    };
    return returnVal;
};

//Then execute it
finalArray = buildObjectGraph(YOUR_RAW_ARRAY);
ericb
  • 3,400
  • 1
  • 21
  • 21
  • hey great thanks! is there some way to optimize in there by removing items in the RAW array that have already been pushed? – billy jean Sep 13 '11 at 22:01
  • I have really looked at trying to `splice` out the pieces of the input array during processing, but since both functions are using pointers back to the `inputArray` that would really mess up the iterator trying to loop through each item. Also, looking at perf of splicing up different arrays to pass to the `findChildren` function you might not actually be better off as this can have some overhead. Lastly, checking the `.length` property of an array does slow things down a bit (especially on large arrays). It's much better to cache it first in a variable and then loop against that. – ericb Sep 13 '11 at 23:00
0

When you build a "tree builder function" you have to decide if the "top level thing" is a single item or an array of items. Since you said itemS we go with an array. The difference is the parameter you pass in and get returned back, if its an array we pass the parentId, otherwise we pass the id.

function buildTree(parentId, list) {
  var nodes = [];
  for (var i=0, l; l = list[i]; i++) {
    if (l.parentId === parentId) {
// if you need "myList" intact afterwards remove the next line at the cost of efficiency
      list.splice(i, 1); i--;  
      nodes.push({
        id: l.id
        ,parentId: l.parentId
        ,name: l.name
        ,children: buildTree(l.id, list)
      });
    }
  }
  return nodes;
}

var myTree = buildTree(null, myList);
James
  • 20,957
  • 5
  • 26
  • 41
  • The only major gripe i have about a recursive solution (or rather, the recursive solutions i've seen and thought about) is that it'd be insanely slow for large numbers of nodes. Each non-root node will require scanning the entire array for its children, making the algorithm O(n^2) -- or worse, unless array pushes are constant-time. It's conceptually simpler, but that doesn't matter a lot if it takes a day to run. :) – cHao Sep 13 '11 at 23:01
  • Fixed - remove elements as they are found - well it's better but still not superfast. – James Sep 13 '11 at 23:08
  • Unfortunately, AFAIK splicing an array is an O(n) operation. For really large arrays, this might actually slow it down, as you're now potentially at O(n^3). – cHao Sep 13 '11 at 23:20