mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-16 14:49:09 +02:00
8a0934c741
The @mention popup tracked the highlighted row with a positional integer (selectedIndex into displayItems), but rows are rendered in the re-bucketed order produced by groupItems() (current → recent → search → users → issues). An async server "search" result is appended to the END of displayItems yet hoisted near the TOP on render, so the highlighted row and the committed item pointed at different entries — you navigate to one target but mention its neighbour. A separate useEffect also force-reset selectedIndex to 0 on every displayItems change, snapping an active selection back to the first row whenever async results landed. Root cause: a slot index is not a stable target for a list whose order and length change asynchronously. Track selection by item identity instead: - Replace selectedIndex state with selectedKey (the item's `type:id`). - Derive groups/orderedItems (the exact rendered order) and resolve the numeric index from selectedKey against orderedItems; fall back to row 0 when the pinned item is gone or nothing is picked yet. - Keyboard nav, Enter, clicks, highlight, and scroll all index orderedItems, so the highlighted row always equals the committed item. - Drop the force-reset effect; identity-based selection self-heals across reorders and async arrival without resetting an active pick. Adds a regression test asserting the highlighted row equals the committed item when groupItems reorders the list, both initially and after ArrowDown. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>