Extend QueryMatcher's sorting heuristic

[jugglinmike]

Use the order of the input keys as a signal for relative importance of
matches.

Signed-off-by: Mike Pennisi [email protected]

---

This is intended to resolve riot-web issue #13415. In that issue, Command completion was considering a match for one command's name to be equally strong as a match for another command's arguments (since both occurred at string position zero). By falling back to the original sequence of the objects, the UI presented the matches in an arbitrary (and sometimes undesirable) order.

[jugglinmike]

instead of bloating this map by splitting the keys into {key,index}
could we not optimize given that we only actually ever care about the "highest priority" (lowest weight) and thus just store the Min(weight) in the Value (along with T[]) that we find when building the _items map?

Thanks for the review, @t3chguy! I hear what you're saying about bloat, but I don't think we can address it exactly as you've suggested. If object A has "foo" as its first key and object B has "foo" as its second key, they'll both end up in the array associated with "foo". If we only store the minimum for both objects, we won't be able to choose between them when sorting.

In terms of types, I think what's needed here is neither

Map<{value: string, weight: number}, T[]>

nor

Map<string, {minWeight: number, objects: T[]}>

but instead

Map<string, {weight: number, object: T}[]>

I've pushed up some code to that effect. Does it look any closer to the mark?

[t3chguy]

I hear what you're saying about bloat, but I don't think we can address it exactly as you've suggested.

You are totally right, I was rusty on this part of the code.

I've pushed up some code to that effect. Does it look any closer to the mark?

The code is better, thanks for the prompt iteration.

Thanks for your contribution and tests!!

[jugglinmike]

My pleasure :)