fix(frontend): show the search dropdown's loading state while a search runs

[DSOTec]

Problem

In app-shell.tsx, showDropdown was only ever set to true inside the search fetch's success branch — never before or during the request. The dropdown itself is gated on showDropdown, and the "Searching..." text lives inside it, gated on isSearching:

{showDropdown && (
  <div ...>
    {isSearching ? <div>Searching...</div> : ...}

So for any fresh search — the common case, where the dropdown starts closed — isSearching was true for the whole debounce-plus-fetch duration while showDropdown stayed false, and nothing rendered at all. By the time setShowDropdown(true) ran, setIsSearching(false) ran in the same tick and was batched with it, so the loading branch was never painted. Users never saw "Searching..."; results just popped in with no feedback.

Solution

Open the dropdown as soon as the query is non-empty, before the debounce starts, so the in-flight state is actually visible:

setIsSearching(true);
setShowDropdown(true);

Two follow-on details:

• The success branch's setShowDropdown(true) is now redundant and drops out. A side benefit: a dropdown the user dismissed mid-request (Escape or click-outside) now stays dismissed instead of springing back open when results land.
• Failed lookups still call setShowDropdown(false). I deliberately kept this: letting a failure fall through to the open dropdown would render "No results found", misreporting a network error as an empty result set.

Behaviour on the success path, empty results, and a cleared query is unchanged.

Testing

Added frontend/src/components/app-shell.test.tsx with 6 tests:

1. "Searching..." is visible during the debounce — asserted immediately after typing, before the 300ms timer elapses
2. ...and still visible while the request is outstanding — using a fetch double that never settles on its own, so the pending state can be observed directly
3. the loading state is replaced by results once the request resolves
4. "No results found" renders for an empty result set
5. clearing the query closes the dropdown
6. a failed request closes the dropdown and does not show "No results found"

Verified the tests actually catch the bug: against the code before this change, tests 1, 2 and 6 fail (Unable to find an element with the text: Searching...) while 3, 4 and 5 still pass — confirming the fix targets the loading state without regressing the paths that already worked.

Full suite from a clean npm ci, matching what CI runs:

npm test          13 files, 109 tests passed   (also verified with CI=true)
npm run lint      0 errors
npm run build     OK
npx tsc --noEmit  clean
npx playwright test   2 passed
npx lhci autorun      exit 0 (warnings only, no failed assertions)

Note on the first commit

This branch carries two commits. The second (fix(frontend): show the search dropdown's loading state...) is the actual fix for #1063 and is a 6-line change.

The first commit is the CI-pipeline repair already submitted as #1071, included here only because main is currently red — Frontend CI, Lighthouse CI and E2E (Playwright) all fail on main, so a branch based on it cannot go green on its own. If #1071 merges first, I'll rebase and that commit disappears from this PR, leaving just the app-shell.tsx change and its tests. Reviewing frontend/src/components/app-shell.tsx and app-shell.test.tsx alone gives the complete picture of this fix.

Closes #1063

[drips-wave]

@DSOTec Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits