Example of Column Oriented DataSource & Aggregation

[Dwaynekj]

The following in a suggested implementation of a {{getRow}} that consists of a getter for each of two known columns, ({{height}} and {{weight}}.

The idea of using getters here is to prevent a {{getRow}} implementation from deref'ing all column arrays. With getters each column is only deref'd when accessed.

function Row() {}
Row.prototype = {
    get height() { return column[1][this.n]; },
    get weight() { return column[0][this.n]; }
};

var column = [
    [222,180,145,240],
    [60,61,62,63]
];

var row = new Row();
row.n = 3;
row.height; // 63
row.weight; // 240

row.n = 1;
row.height; // 61
row.weight; // 180

function getRow(n) {
    row.n = n;
    return row;
}

var dataRow = getRow(2);
dataRow.height // 62
dataRow.weight // 145

Generalized:

function Row(fields) {
    this.rowIndex = 0;
    fields.forEach(function(fieldName, columnIndex) {
        Object.defineProperty(Row.prototype, fieldName, {
            get: function() {
                return column[columnIndex][this.rowIndex];
            }
        });
    });
}

DataSourceColumn.prototype.setFields(fields) {
    . . .
   row = new Row(fields);
};

DataSourceColumn.prototype.getRow(rowIndex) {
    row.rowIndex = rowIndex;
    return row;
}

[Dwaynekj]

@joneit has added a version of the above "generalized" code to the Computed Cells & Columns wiki page.

[Dwaynekj]

Alternatively and more drastically, all calls to getRow could be removed. Usages on [this]commit(https://github.com/openfin/fin-hypergrid/commit/275ec5c7c39c02489f88bb7bc78a863a0b91aade) are

       filterSubgrid // addon overrides it. Will be removed
       totalsToolkitSummarySubgrid // addon overrides it. Will be removed
       simple-sorting-pipeline // Will be removed
       sorting-example 

      grid->behavior->dataModel + subgrids-> dataSourceOrigin-> Pipeline Objects..getRow
      behavior.get/setRowHeight
      behavior.clearAllCellProps
      dm.getIndexedData

      cellEvent.dataRow //Critical

      selection.getRowSelection
      selection.getColumnSelection
      selection.getRowSelectionMatrix
      selection.getColumnSelectionMatrix
      selection.getSelection
      selection.getSelectionMatrix

[Dwaynekj]

Discussion with @stevewirts

"Hypergrid Thoughts..

the DataOrigin object should have a simple API that would look something like this,

getValue(x, y)
setValue(x, y, value)
getRowCount()
getColumnLabel(x)
getColumnType(x) - optional, but would make a huge difference in analytics for sorting/bucketing purposes
addDataChangedListener(callback)

Everything else is built on top of this.
This default DataOrigin object should be easy to replace (maybe passed in with config?)
The analytics should sit on top of this.
Row Objects should be avoided at all cost.  The inner workings of hypergrid should not use row objects.
To support application developer API hypergrid would have to provide them (generate them on the fly), but not use them internally. 
This would provide for a more general grid control as it would be trivial to support both column and row oriented data structures.
When the datachanged listener is fired, the analytics should be re-applied, sorts/filters/aggregations/etc.
Don’t assume the getValue/setValue functions deal only with primitives, they should be free to take/return anything; numbers, dates, strings, objects, arrays, etc…

The ideal scenario for any high performance frontend gui display (like a grid or chart) is for the program to not have to transform the data in order for it to be used.
The above API should stay small and simple as developers should be able to implement it very easily for any shape of data.

Also take a look at this grid, It is probably the leading competitor for hypergrid.  It’s DOM based and has all the features of a great general grid control.
https://www.ag-grid.com/"