-
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
[HOLD for payment 2024-03-14] [HOLD for payment 2024-02-07] [$500] HIGH: Mark the chat as "read" immediately upon switching to the tab #33680
Comments
Job added to Upwork: https://www.upwork.com/jobs/~01962a536f7d747895 |
Triggered auto assignment to @bfitzexpensify ( |
Bug0 Triage Checklist (Main S/O)
|
Triggered auto assignment to Contributor-plus team member for initial proposal review - @abdulrahuman5196 ( |
ProposalPlease re-state the problem that we are trying to solve in this issue.chats are not marked as "read" immediately when a user switches to the chat tab. What is the root cause of that problem?the read status of a chat is not updated in real-time as the user views it. Instead, the status update appears to be dependent on a state change triggered by navigating away from and back to the report What changes do you think we should make in order to solve the problem?React Native's AppState can be used to determine if the app is in the foreground or background, and the useEffect hook can be employed to run side effects based on state changes. Here's a proposed solution: Import AppState from React Native: This module helps to determine the current state of the app. Add AppState Listener in useEffect: We will add a listener to AppState to detect when the app is brought to the foreground. Update Read Status: When the app comes to the foreground and the relevant chat tab is active, we trigger the action to mark the chat as read. import { AppState } from 'react-native'; useEffect(() => {
const handleAppStateChange = (nextAppState) => {
// Check if the app is coming to the foreground
if (nextAppState === 'active') {
if (Visibility.isVisible() && Visibility.hasFocus() && ReportUtils.isUnread(report)) {
// mark the chat as read
Report.readNewestAction(report.reportID);
}
}
};
AppState.addEventListener('change', handleAppStateChange);
return () => {
AppState.removeEventListener('change', handleAppStateChange);
};
}, [report.reportID]); What alternative solutions did you explore? (Optional) |
ProposalPlease re-state the problem that we are trying to solve in this issue.This is new feature, we want to mark chat as read when the chat gains focus. What is the root cause of that problem?This is new feature. What changes do you think we should make in order to solve the problem?
This can be reused for various use case in the app
Basically if the user comes back to the screen and the user is viewing the latest messages, then call
We can optionally add
To here because we don't need to recalculate the green marker if the screen is not visible. Inside Note:
What alternative solutions did you explore? (Optional)We can modify this existing logic to handle the above cases, and we need to make sure to add screen visibility to the dependency list here |
Proposal updated to clarify and add example code changes |
@quinthar I have some suggestions
Nope. Now unread marker will only display if you open the report while it has unread messages. If you are already on the report and you receive message while you 're on another tab and switch it back it will not display the marker.
Then what is the reason to display the marker if we remove it immediately, in any other social media apps (e.g. telegram) the marker will exist until you open other chat and I think the current behaviour is correct. |
@abdulrahuman5196 this is one marked as critical, so please prioritise reviewing the proposals here - thanks! |
Ah, good questions! To clarify, I'm not referring to the "unread marker" (eg, the horizontal line across the chat that designates new from old messages). I'm referring to it being marked as unread (bold) in the LHN. I'm sorry for being ambiguous in the original description, does that clarify things? |
ProposalPlease re-state the problem that we are trying to solve in this issue.Mark the chat as "read" immediately upon switching to the tab What is the root cause of that problem?New Feature: App/src/pages/home/report/ReportActionsList.js Lines 207 to 209 in 88d837c
but it only marks the report read if it is What changes do you think we should make in order to solve the problem?We should add visibility change listener and should CAUTION: we should not reset So inside
or We can also use this code App/src/pages/home/report/ReportActionsList.js Lines 207 to 209 in 88d837c
but we should add visibility state as a dependency here
What alternative solutions did you explore? (Optional) |
Bump @abdulrahuman5196 - please review these proposals, thank you! |
Proposal updated with minor change, based on the requirement update |
@abdulrahuman5196 please take a note that this is not a minor change but the main point of the new feature we are implementing. As only making the report unread and not resetting |
Reviewing now |
Current Experience: Screen.Recording.2024-01-01.at.11.33.07.PM.mov
I think there are 2 issues here regarding the LHN and unread marker here I think in the step 3, we should change the experience like. If we fix step 3, in step 4 the chat would automatically act as already read chat. Kindly let me if we should change the unread marker as suggested or just have the LHN issue as mentioned in OP. |
@bfitzexpensify, @abdulrahuman5196 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
@abdulrahuman5196 in step 4, when the user switches away, that would remove the green unread marker? |
That should be the case IMO, but not happening right now. Atleast in this case if we switch to chat B and come back to chat A after step 3, we are seeing unread marker. |
Sweet. Looks like you're up on reviewing the fix @abdulrahuman5196 |
Whoops, I missed that @bfitzexpensify is back online: I'm stepping away here and Ben will deal with the BZ next steps when that time comes. |
Mind taking a look at the PR @abdulrahuman5196? |
Hi @bfitzexpensify Sorry for the delay. Will check on it today. |
@abdulrahuman5196 what's the latest with this issue? |
@bfitzexpensify new changes have been merged yesterday |
yep the pr was merged |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.48-0 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2024-03-14. 🎊 For reference, here are some details about the assignees on this issue:
|
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
|
Payments complete, please complete the BZ checklist when you get a moment @abdulrahuman5196 - thank you! |
Not a regression. New implementation.
Yes.
|
I think we can close this @bfitzexpensify |
Current behaviour:
Expected behaviour:
In step 3, LHN shouldn't be bold, though it should have the green unread marker should be shown to symbolize the new messages received.
When the user switches away, the green unread marker should be removed.
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: