Every state/count change in toggleFavorite was applied only after the
network round trip to this app's home-NAS-hosted Gitea completed, so a
tap visibly did nothing until that finished -- reported as feeling
laggy. The star/count now update synchronously on tap, before the
coroutine launches; a failed request rolls the optimistic change back
instead of leaving the display stuck at it. FAVORITES-list unstar (row
removal) stays non-optimistic, since reverting a removed row is more
jarring than reverting a color/count.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The prior fix for double-counting used an early-return guard that made
a repeat tap on an already-Starred row do nothing -- fixed the count
bug but also made the star impossible to undo from the ALL list.
Replaced it with a real toggle: an already-starred-this-session tap
now calls unstar() and decrements the count back down instead of being
inert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
toggleFavorite's ALL-list success branch updated favoriteAction to
Starred but never touched starsCount, so a row kept showing its
pre-star count even after the server had actually accepted it. Now
increments starsCount by 1 in the same update. Also guards against a
repeat tap on an already-Starred row (the ALL list can't tell a
repo's already-starred state on load, so the star stays tappable)
double-incrementing the displayed count.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
