Refactor code to improve unread marker logic#18637
Refactor code to improve unread marker logic#18637MonilBhavsar merged 56 commits intoExpensify:mainfrom
Conversation
# Conflicts: # src/libs/actions/Report.js # src/pages/home/report/ReportActionsList.js
…/App into monil-fixNewMarkerLine # Conflicts: # src/libs/actions/Report.js
|
I have updated base branch so we stay up to date with main |
41602a4 to
52cf638
Compare
…il-fixNewMarkerLine # Conflicts: # src/libs/actions/Report.js
|
Thanks! I can verify on my side |
|
Confirmed! works for me too |
|
Let's ship it!! 🚀 |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
@gedu I think we should unsubscribe the typing event in the Need to create cleanup function here which calls App/src/pages/home/report/ReportActionsView.js Lines 86 to 89 in c435734 |
Hey, the next |
|
@gedu could you check if this issue was caused by this PR? |
|
🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 1.3.56-0 🚀
|
| if (!messageManuallyMarked.read) { | ||
| shouldDisplayNewMarker = shouldDisplayNewMarker && reportAction.actorAccountID !== Report.getCurrentUserAccountID(); | ||
| } | ||
| const canDisplayMarker = scrollingVerticalOffset.current < MSG_VISIBLE_THRESHOLD ? reportAction.created < userActiveSince.current : true; |
There was a problem hiding this comment.
@MonilBhavsar Actually, canDisplayMarker is wrong whenever we create a new action and mask as unread this action. That makes currentUnreadMarker isn't updated correctly. The reason is the newest action has reportAction.created is always bigger userActiveSince.current.
Screencast.from.22-08-2023.17.26.27.webm
|
Evaluating the deploy blockers related to this PR, it seems there are three:
|
|
🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.56-24 🚀
|
|
|
||
| // This callback is triggered when a new action arrives via Pusher and the event is emitted from Report.js. This allows us to maintain | ||
| // a single source of truth for the "new action" event instead of trying to derive that a new action has appeared from looking at props. | ||
| const unsubscribe = Report.subscribeToNewActionEvent(reportID, (isFromCurrentUser, newActionID) => { |
There was a problem hiding this comment.
Hi, coming from #26432
The issue is a regression from this removed, where the current user doesn't scroll to the bottom after sending a message.
I have several questions regarding these changes:
- Are the current users not scrolled to the bottom after sending a message is expected?
- If not, can we reintegrate the listener
Report.subscribeToNewActionEventto scroll the current user when sending a message? Or there's a performance consideration to use that listener.
There was a problem hiding this comment.
Are the above results expected?
Sorry, what result?
There was a problem hiding this comment.
Ahh, sorry for not making it clear.
Sorry, what result?
The current user doesn't scroll to the bottom after sending a message when they're not at the bottom of the chat.
There was a problem hiding this comment.
That does seem like issue. We should definitely scroll user to the bottom
There was a problem hiding this comment.
@MonilBhavsar Is there any drawback or performance issue if we use Report.subscribeToNewActionEvent to get the current report action?
There was a problem hiding this comment.
I don't think it will have an impact on performance, it will be mainly just to know when a new message is sent. Because this newActionEvent only listens to comments sent, and not received from others.
|
|
||
| return null; | ||
| }} | ||
| keyboardShouldPersistTaps="handled" |
There was a problem hiding this comment.
keyboardShouldPersistTaps is set to "handled" is causing keyboard not closing when tapped outside. #53196
| onScroll(event); | ||
| }; | ||
|
|
||
| const scrollToBottomAndMarkReportAsRead = () => { |
There was a problem hiding this comment.
Hi team, coming from #54944. We should use useCallback here to avoid unnecessary rerenders of FloatingMessageCounter
| * @param {String} reportID | ||
| */ | ||
| function readNewestAction(reportID) { | ||
| const lastReadTime = DateUtils.getDBTime(); |
There was a problem hiding this comment.
We should had used getDBTimeWithSkew here, this caused #54679
Details
Fixed Issues
$ #23171
PROPOSAL: GH_LINK_ISSUE(COMMENT)
Tests
Have two users A and B
Active chat case
Inactive chat case
Mark as unread
Deleting a message
Scrolled up
Offline tests
None, same as online(As message sending and receiving is halt when offline)
QA Steps
Please see Tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
unreadMarker_chrome.mp4
unreadMarker_safari.mp4
Mobile Web - Chrome
Mobile Web - Safari
unreadMarker_iosSafari.mp4
Desktop
unreadMarker_desktop.mp4
iOS
unreadMarker_ios.mp4
Android
unreadMarker_android.mp4