-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: re-calc the marker when msgs are deleted #42742
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
6e8dc5d
fix: re-calc the marker when msgs are deleted
dominictb 844e6bf
fix: lint
dominictb 88f5d9d
fix: set the unread marker logic
dominictb 6e1cb4f
fix: prettier
dominictb 5941b95
Merge branch 'main' into fix/41935
dominictb cc42221
fix: move the set markerLastReadTime outside the loop func
dominictb fbad958
chore: add unit test
dominictb b7f75ef
fix: update lint for test
dominictb File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to save the
lastReadTime
in a ref twice? It is already being saved here:App/src/pages/home/report/ReportActionsList.tsx
Line 198 in b7f75ef
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arosiclair in my proposal #41935 (comment) it should have been explained clearly. In short, the original issue here is because the
lastReadTimeRef
is tied tightly withreport.lastReadTime
, so in case we re-calculate the unread marker, thelastReadTimeRef
has been updated withreport.lastReadTime
value, causing the unread marker to disappear.My main solution is that we will persist another
lastReadTimeRef
, calledmarkerLastReadTimeRef
which is tied to thecurrentUnreadMarker
, i.e: it will be set withlastReadTimeRef.current
if the unread marker first appears during calculation (changing fromundefined
-> defined value), and it shouldn't change its own value if the unread marker still exists in the screen. We'll clear themarkerLastReadTimeRef
if the unread marker disappears from the screen (changing fromdefined value
->undefined/null
)Hope that's clear!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where exactly is this happening? Is there a way we can prevent that from happening? From what I understand, the marker time should only change when the user marks a message as unread. So any other change would be unintended.
Let's try fixing the original
lastReadTimeRef
before adding another one since this functionality is already confusing and complex as it is.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arosiclair as explained in my proposal as well as here, the
lastReadTimeRef.current
has already been set to thereport.lastReadTime
the first time the unread marker is calculated, and it stays the same after that (or changes if thereport.lastReadTime
changes). Hence, we couldn't uselastReadTimeRef
to re-calc the marker in case thesortedVisibleReportActions
changes.(And you already approved my proposal 😅 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, I hired you for the job but your proposal was not fully satisfactory. Please work with me to get this PR in a better place.
I'm asking these questions again, please answer them directly: When the message is deleted, where exactly is the
lastReadTimeRef
being cleared? Is there a way we can prevent that from happening?If the answer is yes (I believe it is), then we shouldn't need to save the time for the marker twice. Instead we can just fix the issue where
lastReadTimeRef
is being cleared when it shouldn't be.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lastReadTimeRef is tied to the
report.lastReadTime
in here. The thing is, when you open a report, the unread marker will be calculated using the oldreport.lastReadTime
(which is saved inlastReadTimeRef.current
) in here. However, after a short while, the OpenReport API (see the image below) has updated thereport.lastReadTime
to a new timestamp (which is larger than the last message timestamp).However, since the unread marker has already been set, in here the
calculateUnreadMarker
function will still render the unread marker. Now when a message associated with the unread marker is deleted, we face 2 issues:shouldDisplayNewMarker
here is trying to compare the message with the outdatedcurrentUnreadMarker
(which associated message has been deleted).lastReadTimeRef.current
to calculate new marker since thereport.lastReadTime
has been updated to a timestamp larger than the latest message timestamp as mentioned aboveWe'll still need a FE change to fix (1)
For (2) either we can fix the
report.lastReadTime
in the OpenReport API (which I think this involves lots of complication, asreport.lastReadTime
is used elsewhere, e.g: showing the unread status of the report in LHN), or we can employ the solution in this PR (which is fully FE, more simple and elegant which doesn't touch thereport.lastReadTime
value)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arosiclair hope that's clear enough for you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation. I took a closer look at this component and realized it needs a bit of a refactor to fix this issue properly and I can't really communicate that through PR comments. I'm going to merge your changes since they work and are covered with tests but I'm also going to make a follow up issue to clean this up.