-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Description
Feature Description
I think that current notification system could benefit from not requiring a page reload as this makes marking a lot of notifications as read really tedious. To better illustrate my point let's compare the Github web notifications with Gitea.
- On Github I can unsubscribe from that notification source from the UI, which saves few clicks and page loads. This is very useful, if one gets ton of notification from the repository, which are of no interest to them.
- On Github visiting the notification marks it at read but doesn't hide it from user until they mark it as done. Gitea on the other hand moves them to
Read
category, hiding them from user, making theread
more equivalent to Github'sdone
. - On Github I can marking notification as
done
doesn't cause a full page reload, making it more manageable to work on going though notifications. On Gitea marking notification as read causes a full page reload, where it could just remove the notification from the page. - On Github flagging a notification (or saving in their terms) makes the notification visible in it's own tab as well as the current one. Gitea shares pins between the
Read
andUnread
tabs. - Moving a notification from
done
toinbox
on github doesn't redirect me toinbox
on first click. In Gitea marking notification as unread redirects me toUnread
tab.
Some of those might be deliberate design choices which I'm not aware of but I'm looking forward to some thoughts about this.
I'll have to look into this more to propose something more concrete than "Don't redirect and avoid full page reload" as I haven't touched templates and frontend much. This could probably be rewritten to use htmx/datastar, but I'll have to read more on this. My initial proposal is to address 1,3 and 5 as 2 is technically correct (user did read the notification) and 4 isn't really a big issue.
Screenshots
No response