feature/improve-navigator-ordering

[EliotRagueneau]

Fix 2 problems:

• Avoid floating predicted complexes components because they are "not found" in any complex (Ndc80 search)
• Avoid instability in results arising from race conditions between timesAppearing definition and timeAppearing usage

Also improve sorting of components when similar timesAppearing and similar first index appearing.

This improvement needs to be discussed and reviewed because it is significantly longer (+17,52% compute time for a relatively big example (20 complexes x 272 components, still marginal time though from 7ms to 8,5ms)

See comparison at https://docs.google.com/spreadsheets/d/1oG9kVww2F1s5U2EjoataKmOiVaY4yx4dXloqJJGqBAc/edit?usp=sharing

[EliotRagueneau]

Previous sorting: Sort by firstIndex, then if equal, by amount appearing

New sorting: Sort by all indexes of apparition

• if component A appears more time than B, then component A is placed first (keeping the behaviour of gathering shared component at the end for the stairs effect)
• If they have the same first index of apparition, we compare the second, and then the next ones until there is a difference or we ran over all apparitions. This makes basically sorted first by the first complex they appear in, then by the sceond complex they appear in, etc, creating again a kind of staircase effect

[EliotRagueneau]

These are extremely rare conditions though, as you need to have different complexes having the same amount of component shared with another one, but not the same components. Here for instance all components have a first index of 0, so then they are all compared based on the timeAppearing, but they are all appearing only 2 times, so they are considered equal by our sorting algorithm, and therefore don't get sorted between one another.

Therefore, I think the proposed solution is better, but I don't know if it's worth a 20% increase of compute time, what do you think @jmedinaebi ?

[jmedinaebi]

Looks good, just a couple of minor comments.

[jmedinaebi]

In this method, we are updating this.navigatorComponents() and also returning and setting the returned value to navigatorComponentsTA(), so this.navigatorComponents() and navigatorComponentsTA() are equals. We should treat this.navigatorComponents() as immutable, creating a new array and returning the new array.

[jmedinaebi]

Also, are we not using navigatorComponentsTA in the HTML at all?

[jmedinaebi]

I just pushed a change for renaming navigatorComponentsTA and also to use the new variable instead of navigatorComponents.

[jmedinaebi]

I have pushed a new commit to show the loading spinner when the user makes a new query, instead of just showing the old results until the new ones come in. I have deployed my changes (this and the previous commit) to the github pages.

I have also restarted Complex-WS and SOLR in the public instances to see if that improves things, as queries were being slow this morning.

[EliotRagueneau]

#d388b28 Is really important because I realised every time we update the display options or the sorting or grouping, we were triggering a new search API call, which was making everything slow. Thanks to this one, we now send requests only when an actual parameter of the search has changed. Also make sures that we only triggers the preparation of components and the sorting when actually needed, not whenever you change something.

[jmedinaebi]

Just a few comments on the latest changes.