JimLiu/angular-ui-tree — pull request #310 by robwhess (2014-12-17 01:46:33+00:00)
Title: Handle null node in collapseOrExpand().

This should fix a bug that came up for me using the current distribution. In my app, I am displaying a potentially huge tree, where each node has a lot of information associated with it, most of which is watched by Angular. This causes incredible lag/freezing as Angular tries to process all of its watchers, so I'm creatively using `ng-switch` to only insert children into the DOM when necessary (upon expand). My node template looks something like this:

```html

{{lots of watched stuff}}

```

When I do this, however, and then call `collapseAll()`, I get this exception, which I traced back to `collapseOrExpand()`:
```
TypeError: Cannot read property 'collapse' of null
```

The change in this PR *should* fix this bug. Unfortunately, I haven't been able to test it in production (I tested it by directly modifying the old `angular-ui-tree.js` from `dist`) because the new code (built from `master`) results in some very strange behavior for me. Specifically, I use this function, as you do in your demo, to get the tree root scope (the tree is given the id `tree-root`), which I then use to call `collapseAll()`:
```js
function getTreeRootScope() {
var elem = angular.element('#tree-root');
console.log(elem);
return elem.scope();
}
```
(I've also used `document.getElementById()` here, exactly as you do in your demo with the same results described below.)

Calling that function when using `angular-ui-tree.js` built from `master` results in the `console.log()` line being printed thousands upon thousands of times, and this eventual exception:
```
RangeError: Maximum call stack size exceeded
```
However, If I call that exact same function when using `angular-ui-tree.js` copied directly from dist before building anything, the `console.log()` line gets printed once, as expected, and I get the correct scope returned.

I don't understand this behavior and haven't been able to investigate it much, and it likely belongs in a different issue, anyway. I'm describing it here just because it relates to this PR.

Anyway, again, the PR *should* fix the original bug. Let me know if you have any feedback here.