The search list shows one row per code, and it is always the `-a` variant. This was decided in #22: the user picks the variant on the detail page. That choice has two consequences that the interface has to handle. ## Background Some elements and vaults have the same code and the same value but several ways of performing them. Code `UB-1.206` has two: - `UB-1.206-a`: "Free straddle jump over LB to hang on HB" (legs apart) - `UB-1.206-b`: "Hecht jump (legs together) with hand repulsion over LB to hang on HB" (legs together) They are two separate rows in the database, but the list shows only `-a`. The search looks in the words of **all** variants of a code, so a word that is only in `-b` still finds the code. ## The two problems 1. **Nothing in the list says that there are more variants.** The user cannot see that `UB-1.206` has a second way of performing it before opening the detail page. 2. **A match can look wrong.** A search for "hecht" finds `UB-1.206`, but the row shown is `-a`, whose text does not contain "hecht". The user sees a result that seems not to match what they typed. The same happens for "stoop" (`UB-1.102-b`) and "straddle" (`UB-1.103-b`). ## From the review of the search (PR #52) From @anettkva: > **Showing variants in the search list.** This is a frontend change. `variants` is already in the API, so no backend change is needed. Showing one row per code was decided in #22, and the user picks the variant on the detail page. I suggest writing a separate issue for it. From the comment on the same PR: this was meant as a deliberate decision, but then the interface should have an indication that there are several variants, and it does not have one now. ## Proposal - Keep one row per code (the decision in #22). - Show a small indication on a row when the code has more than one variant, for example "2 variants". Use `variants` from the API (check in the resolver whether it includes the item itself, so the count is right). - When the search text matches a word that is only in another variant, show that variant on the row (its description, or a line such as "also matches: Hecht jump (legs together) …"), so the match does not look wrong. The interface has the search words and the descriptions in `variants`, so it can check this itself with the same word rules as the backend (lowercase, no accents; see `normalizeWords` in `backend/src/catalog/words.ts`). - Link the row to the detail page, where the user picks the variant (#48 is the variants list on that page). ## Done when - [ ] A row for a code with more than one variant shows how many variants there are - [ ] A search that matches only in another variant shows which variant matched - [ ] The indication does not depend on colour alone, and has a text for screen readers - [ ] A component test covers a code with one variant, a code with several, and a match in the second variant (for example "hecht") - [ ] The README or `docs/UI_PLANS.md` says that the list shows one row per code and how variants are shown ## Open question Should the backend tell the interface which variant matched (for example a `matchedVariantId` on a search result)? It is not needed for the first version, because the interface can check the descriptions itself. It would remove the need to repeat the word rules in the frontend, so it is worth deciding if the check turns out to be fragile. Related: #41 (result overview and table), #48 (variants list on the element page), #22 (one row per code), #24 / PR #52 (the search).