Partially refresh notifications list#35010
Conversation
|
Could you elaborate what's the goal of this PR and what problem it would fix? IMO we could:
Then everything could be simplified, and user experience is still good. |
The goal of the PR is to improve UX when checking notifications. I am using the notifications as my entrypoint for most interactions with Gitea and as something like a ToDo list. Currently marking several notifications as read is pretty slow for me as you have to wait for the full page reload to check the next entry (especially on larger instances or when having a slower connection to them). |
Then I think we need to add some checkboxes like GitHub, but not "partially refresh". "partially refresh" won't make noticeable speed-up. |
|
I'm definitely in favor of dropping the (buggy) SSE code. Websocket is the final goal, but I can accept a polling-based approach as an interim solution which should be much easier to implement. |
|
I've fixed the htmx code now, the status post was missing the
I would say it does. Loading the complete page and assets again is quite a bit slower and lets the browser flicker, so staying at the same position and clicking on one notification after another is no fun. Added a recording to the description that shows how it works using a fast but not instant 4g connection. |
| {{if eq .Status 1}} | ||
| {{ctx.Locale.Tr "notification.no_unread"}} | ||
| <div id="notification_table"> | ||
| {{range $one := .Notifications}} |
There was a problem hiding this comment.
Why not keeping notification instead of one?
There was a problem hiding this comment.
Using $notification in the code below will make the line unnecessarily long .... we will get:
{{$notification.Repository.FullName}} {{if $notification.Issue}}<span class="text light-3">#{{$notification.Issue.Index}}</span>{{end}}
I think $one.ID is clear enough
| } | ||
|
|
||
| statuses := []activities_model.NotificationStatus{status, activities_model.NotificationStatusPinned} | ||
| statuses := []activities_model.NotificationStatus{queryStatus, activities_model.NotificationStatusPinned} |
There was a problem hiding this comment.
The pinned status would still appear in both lists which is somehow strange IMO. No idea what the best way to improve would be as I am in general not 100% sure how ppl use this. Would it make sense to put pinned entries to the top?
There was a problem hiding this comment.
Leave the problem to the future?
|
Done from my side, much more changes than I thought ..... |
* giteaofficial/main: Fix ListWorkflowRuns OpenAPI response model. (go-gitea#35026) Partially refresh notifications list (go-gitea#35010)
This PR prevents full reloads for the notifications list when changing a notifications status (read, unread, pinned).
Currently marking several notifications as read is pretty slow for me as you have to wait for the full page reload to before marking the next entry as read (especially on larger instances or when having a slower connection to them).
as discussed in #33465
Before:
Notifications.-.Gitea_.Git.with.a.cup.of.tea.-.Google.Chrome.2025-07-09.14-29-25.mp4
After:
Notifications.-.Gitea_.Git.with.a.cup.of.tea.-.Google.Chrome.2025-07-09.14-31-12.mp4
Todos / open questions