Review the Javascript about the evidence table for performance and code quality.

[marco-brandizi]

The function createEvidenceTable() in evidence-table.js has poor code that performs badly.

• values is a bad name, it actually means row or rowValues

• values[0], values[1], values[] everywhere is kindergarten programming, which makes the code unreadable and error-prone. At the top of the row-rendering iteration, it should have something like:

var [ conceptType, conceptLabel, pvalue, ... ] = values // or, as said, 'row'

And then the semantically-meaningful names should be used, not the damn indices, even Assembler programmers use symbolic constants to index memory!

• userGenes is turned into an array (via String.split()) for the sole purpose of counting how many genes there are in the string. This is likely to be the performance bottleneck we're currently experiencing.

The count should be based on the no. of ',' (in a non-empty string) + 1. Write a support function (or use some existing lib) to count the occurrences of a substring in another via indexOf(), as shown here.

==> this is a temporary quick fix, the alternative is to take more time to change the API and make it return the count.

• This is redundant ugly code:

table += '<option value="1000"' + (rows == 1000 ? 'selected' : '') + '>1000 </option>';
table += '<option value="500"' + (rows == 500 ? 'selected' : '') + '>500</option>';
table += '<option value="200"' + (rows == 200 ? 'selected' : '') + '>200</option>';
table += '<option value="100"' + (rows == 100 ? 'selected' : '') + '>100</option>';
table += '<option value="50"' + (rows == 50 ? 'selected' : '') + '>50</option>';

Write a support function (even an anonymous in-line function is better than the current copy-paste mess) which loops over rowsLimit = range of 50, 100, 200, 500, 1000 and writes the <option> row only once.

Generally speaking, in future we should review these mixes of HTML and javascript, see #725

• Various other improvements (can be done later) added as TODO comments in the code.

[marco-brandizi]

When cutting the initial list to the top 100, such list needs to be sorted. See #727 regarding getting this from the API. This is still on a branch and needs unit tests + UI tests.

[marco-brandizi]

@lawal-olaotan the initial table sorting is still wrong, see last comments. The other TODOs are not urgent.