Simplify MR User Count refetching
What does this MR do and why?
Remove unused code from merge request count manager
In the old nav we broadcasted MR count updates across different browser tabs. The new nav also has this functionality, but it can be triggered by a simple event. This removes the legacy broadcasting mechanism.
Create more generic fetchUserCounts
The previous iteration of refreshUserMergeRequestCounts
had a promise
based API which wasn't necessary and the name suggested that it only
updated a User's MR counts while under the hood it updated all the
counts.
The function is now co-located with the super sidebar and has been
renamed fetchUserCounts
which is more generic. It is in a separate
file to avoid side-effects when importing, which is ironic, because the
whole function triggers a side-effect.
All the uses of the function have been adjusted as well and tests for them added.
Screenshots or screen recordings
Note: Triggering the fetch of the user count is a little limited, it only works:
- Closing/Re-opening the MR from the "close" button without leaving a note
- Changing reviewers
- Merging the MR
Most notably:
- changing assignees doesn't work
- quick actions to change reviewer/assignee, do not work.
The logic is a little flawed, but we are planning to look at this a little more holistically with #429678. This MR is mainly about refactoring the implementation
Before | After |
---|---|
closing/re-opening/reviewers | Screen_Recording_2023-11-15_at_22.55.03 |
Merging the MR | Screen_Recording_2023-11-15_at_23.02.46 |
How to set up and validate locally
- Go to any MR
- Play with assigning yourself as a reviewer, closing and re-opening the MR
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.