Stop re-ordering notifications when I mark one as read

[alanhogan]

trafficstars

I find it disorienting that notifications rearrange when I am marking some of them as 'read'. Since they group by repo, if I mark one the newest notification from repo B as read, this may cause repo A to jump ahead of repo B in the list.

This can cause mis-clicks and certainly makes me feel like the rug has been yanked out from underneath me.

I would suggest only re-ordering when new results come from the server and/or when the window is closed or blurred and subsequently opened/focused.

[afonsojramos]

@setchy I'm not sure that #1092 solves the issue per se. It does present an alternative fix, but I think that we still could pin the order per fetch, ie, not sorting per render. But maybe this would involve a major refactoring.

[setchy]

Yeah, it's like a small bandaid 🩹 😄

Reopened to keep us on our toes

[bquorning]

I am not sure why this issue was closed again. I am using v5.11.0 and the notifications are definitely still jumping around.

[bquorning]

This issue is still happening on Gitify v6.9.1.

Would it help to have the notification list always ordered alphabetically by repository name?

[bmulholland]

It would, yeah.

@setchy do you have thoughts or plans for tackling this one? Not asking you to make one, more wondering if a contribution should include some of your thinking.

[0xdevalias]

do you have thoughts or plans for tackling this one?

I haven't deeply verified that the code references align; but from a quick skim through, this plan for a 'stable sort' implementation for the 'most recent' mode from GitHub Copilot (GPT-5) sounds like it could work well; and it also includes an optional ability to include the alphabetic sort as a configurable setting for people who might want that.

Take it as a starting point for ideas/iteration rather than a complete plan/solution:

GitHub Copilot (GPT-5) Proposed Solution

Prompt:

Looking at the attached issue, and the code for @gitify-app/gitify, can you outline what the best plan for solving this might be.

Attached Context:

• https://github.com/gitify-app/gitify
• https://github.com/gitify-app/gitify/issues/319

Response:

Here’s a pragmatic plan to stop repository groups from reordering when you mark notifications as read, while still allowing reordering when fresh data arrives from GitHub.

What’s causing the jump today

• The GitHub API returns a flat list of notifications sorted by “most recently updated” (see listNotificationsForAuthenticatedUser). That order is preserved through filtering/enrichment in getAllNotifications and then passed down as-is.
• When grouping by repository, AccountNotifications reduces that flat list into groups and renders Object.values(groupedNotifications) which depends on the encounter order in the flat list. As you mark items read, the underlying flat list changes and the “first-seen” repo order is recomputed, making groups jump around.
  • Relevant code: AccountNotifications.tsx and AccountNotifications.tsx (render)
  • Mark-as-read mutates the list via useNotifications.markNotificationsAsRead, which calls removeNotifications and then setNotifications.

Proposed behavior

• Keep repository group order stable while you perform local actions (mark read/done), and only recompute the order when we receive a fresh set of notifications from the server (e.g., on explicit fetch, focus regain, or background refresh).

Implementation outline

1. Introduce a stable repository order per account

   • In AccountNotifications, maintain a repoOrder: string[] state representing the ordered list of repository.full_name keys.
   • Derive the initial order from “first-seen” order in the current flat list (the same order your current reduce relies on).
   • Maintain repoOrder across updates:
     • Remove repo keys that no longer exist (group became empty).
     • Append any newly-appearing repo keys at the end.
     • Do not reshuffle existing keys on local removals.
   • Render groups using repoOrder.map(slug => grouped[slug]).filter(Boolean) rather than Object.values(...).

2. Recompute order only on fresh fetches

   • Add a lightweight “notifications version” or “fetch sequence” in the notifications context that increments after a successful fetch in useNotifications.fetchNotifications. Expose it in AppContext alongside notifications and actions.
   • In AccountNotifications, reset repoOrder when that version changes. This allows reordering to reflect the latest “most recent repo” signal from the server, while remaining stable during local actions.
   • This aligns with the issue’s suggestion: “only re-order when new results come from the server.”

3. Keep per-repo items stable and preserve existing UX

   • Inside a repo group, render repoNotifications in their existing order; removing one won’t reorder the remaining items today, so this is already stable.
   • Continue using the existing delayNotificationState to drive fade/slide-out animations in RepositoryNotifications.tsx and NotificationRow.tsx so removals feel smooth without shifting other groups.

4. Optional: provide a user setting for group ordering

   • If desired, add a “Group order” setting with options like:
     • “Stable until refresh” (recommended default; the behavior above).
     • “Alphabetical by repo” (always stable, simplest).
     • “Live by most recent activity” (current behavior; not recommended given the UX issue).
   • The stable-until-refresh option uses the versioned reset to adopt new server-driven recency order only after fetch.

5. Tests

   • Add a unit test for AccountNotifications to assert that:
     • Initial repo order matches first-seen order derived from the flat list.
     • Marking the newest notification in the current top repo as read does not change the relative order of remaining repos.
     • After simulating a “version” bump (new fetch), repo order is recomputed and can change accordingly.
   • There’s already a pattern for testing notifications UI in RepositoryNotifications.test.tsx; add complementary tests around AccountNotifications ordering.

Why this is low-risk

• Changes are localized to rendering/grouping logic in AccountNotifications and a tiny addition to the notifications context to expose a fetch version.
• No API shape changes; no backend changes.
• Existing animations continue to work; this just stops unexpected reflows that cause mis-clicks.

If you prefer the simplest implementation with no context changes, you can skip the version token and implement a “monotonic repo order” in AccountNotifications as described in step 1; it will keep order stable across local removals and only append new repos at the end, which already eliminates the frustrating jumps. Reordering on fetch can be added later by introducing the versioned reset.

[setchy]

This issue is still happening on Gitify v6.9.1.

Makes sense, since no PRs have been raised against this issue to resolve it... ;)

Would it help to have the notification list always ordered alphabetically by repository name?

It would... This would match the group by repository behavior of https://github.com/notifications. I do wonder if this should be a user settings on how the groups should be ordered by

[0xdevalias]

I do wonder if this should be a user settings on how the groups should be ordered by

Theoretically, personally, I would prefer it to be sorted by timestamp recency (with the stable sort caveats mentioned above)

In practice; because something (external to this tool, probably the tracking pixel in the email notifications, even though I haven't opened them) often marks notifications read fairly quickly even when I haven't looked at them myself; and because I try and process them fairly quickly anyway, I rarely have a lot that 'build up' in Gitify; so there's usually only 1 or 2 repos there anyway.

I would imagine there are probably enough users out there that would have differing preferences that having it user configurable (assuming it doesn't overly complicate the codebase to do so) would probably be the 'nicest' solution.

[setchy]

It would... This would match the group by repository behavior of https://github.com/notifications.

Correction - the GitHub UI orders the repository groups by recency / timestamp, not simply by their name (case insensitive)

[bmulholland]

Ah yeah... but, "unfortunately," it's not reactive... so as you go down the list, the sort order is stable :).

IMHO that behaviour (sort by recency when opened, remain stable as links are open) is probably what everyone implicitly expects.

[setchy]

Correct - I agree that the UI should be stable upon notifications interactions...

[setchy]

@setchy do you have thoughts or plans for tackling this one?

What this space... 👀