Investigate using d3-hierarchy:stratify to build / manipulate trees

[davidwatkins73]

https://github.com/d3/d3-hierarchy#stratify

[davidwatkins73]

Some basic investigations:

    serviceBroker.loadAppData(CORE_API.MeasurableStore.findAll)
        .then(r => {
            global.raw = r.data;
            global.all = _.concat(
                [ {id: -1} ],
                _.filter(r.data, m => Object.assign(m, { parentId: m.parentId == null ? -1 : m.parentId })))
        });

    global.strat = stratify;
    global.time = (fn) => { const st = new Date(); fn.apply(); console.log('dur:', new Date() - st); }
    global.bh = buildHierarchies;
    global.rep = (fn, amt) => { for(var i =0; i<amt; i++) fn.apply(); }

Findings: d3 is a bit quicker but insists on a root node

[davidwatkins73]

Bumping this back up as may give us an easy performance boost

[davidwatkins73]

Main problem will be reconciling the d3 strict tree approach (single root) with the forest approach used by Waltz (multiple roots).

This can probably be overcome by using a 'fake' root (as shown in the example code above)

[davidwatkins73]

The WIP PR linked to this issue has a rough n' ready prototype for the measurable trees (i.e. on the viewpoint pages). On my mac it's showing a 4-5x speed boost - though the mac is already fast. Would be good to test with a more realsitic tree example and a more typical user machine.

Also the stucture is a bit different. With stratify the original node is stored as a data property on the returned object - this impacts the templates, event handlers etc. So care will need to be taken when moving code over.

[davidwatkins73]

The time discrepancy may be to do with the (deep) cloning performed in the current implementation. This may be excessively defensive.