-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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: notification count for empty reports #30133
Conversation
@cubuspl42 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
src/libs/ReportUtils.js
Outdated
* @param {Object} report | ||
* @returns {Boolean} | ||
*/ | ||
function isEmptyReport(report) { |
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.
Isn't this unused?
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.
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.
Forgot about this. Removed now!
Well, this would undermine the whole proposal selection process... Are you entirely sure that these two conditions are 100% equivalent? I wanted to achieve the effect when it's impossible to have a notification for a report that's not visible in the LHN, as I explicitly stated in my comments on the issue. If it's currently ineffective performance-wise to achieve this effect, we could figure out if there are any ways to speed things up, possibly by creating a single operator with the filtering semantics, like Still, it would be great to get some numbers first to ensure we have a performance problem here. I see that this note is struck-through, you can let me know what made you change your mind in this matter |
@cubuspl42 I initially thought that we will need to supply |
Bump @cubuspl42 |
@allroundexperts Ouch, I was 100% sure I left a comment about my finding. I either didn't submit it properly, or it landed in some other random issue 😶 So here it is: wrong-notification-count-ios-web.mp4wrong-notification-count-ios.mp4Do you see the problem? Things aren't completely reactive. You need to "touch" the system in a way so the count updates properly. Do you also observe this? |
@cubuspl42 Can you please confirm if this isn't an issue on Staging? |
@allroundexperts As I see it, this is related to the new behavior we're implementing. Please test this on iOS, and preferably provide a video, as from your screenshot, it's really not clear that the testing on iOS succeeded. The notification count can't be seen at all. |
@allroundexperts Bump! |
@allroundexperts From my perspective, we're still on:
Also, there are conflicts to be resolved. |
@allroundexperts if you could please take a look at @cubuspl42 comments. This fixes a high priority project issue #31276 |
I think I've missed this bug. Apologies. Fixing right now. |
@cubuspl42 Added iOS native screen recording as requested. |
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
After going back to LHN, that thread becomes a "ghost" thread, right? 11 is a valid number only for a short period of time, right after I mark it as unread. When I leave the thread, it should go down to 10 again. Isn't this the whole point of this issue/PR? I believed we're aiming to introduce an invariant: "A notification count should only include threads that are accessible, i.e. can be navigated to". As I see it, I demonstrate the invariant being broken. |
@allroundexperts Bump. Let me know if this explanation is still not clear. |
@cubuspl42 The issue you are currently having is the reason my proposal focused on hooking into |
@cubuspl42 Fixed the issue. Screen.Recording.2023-11-30.at.5.10.52.AM.mov |
let previousUnreadCount = 0; | ||
let allReports = []; | ||
|
||
const triggerUnreadUpdate = (reports = allReports) => { |
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.
What's the deal with reports = allReports
? Is it ever non-default?
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.
It's never non-default. I've updated the code and removed this parameter.
let allReports = []; | ||
|
||
const triggerUnreadUpdate = () => { | ||
const currentReportID = navigationRef.isReady() ? Navigation.getTopmostReportId() : ''; |
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.
Have you tested this ''
case? I understand the defence-in-depth strategy, but I'm not convinced by this specific implementation of it.
Maybe...
const currentReportID = navigationRef.isReady() ? Navigation.getTopmostReportId() : null;
const unreadReports = _.filter(allReports, (report) => {
const isAccessible = currentReportID !== null ? ReportUtils.shouldReportBeInOptionList(report, currentReportID) : true;
return ReportUtils.isUnread(report) && isAccessible;
});
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.
or : false
, depending on what we want to do in the corner case
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.
This is in accordance with how we're saving currentReportID
in CurrentReportIdContext
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.
Ok
* More info: https://reactnative.dev/docs/interactionmanager | ||
*/ | ||
InteractionManager.runAfterInteractions(() => { | ||
const unreadReports = _.filter(reportsFromOnyx, (report) => ReportUtils.isUnread(report) && report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN); |
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.
Why was the report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN
condition removed?
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.
Because we wanted to sync this exactly with the LHN.
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.
I don't know, did we?
I summed it up before as...
"A notification count should only include threads that are accessible, i.e. can be navigated to".
...in other words...
"A notification count should not include threads that are inaccessible, i.e. cannot be navigated to".
...and I stand with this. It's my personal summary based on my understanding of the issue.
Notification preferences are a user-accessible feature:
We don't want to break this, right? It sounds like a different topic.
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.
I think this is something different. By setting this preference, you're setting if you want to receive a notification for a new message. Changing this won't really effect the count.
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.
In other words, do you suggest that the old code checking for report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN
was a mistake (an unnecessary / irrelevant check)?
Or maybe that the user setting I added a screenshot of is not actually related to report.notificationPreference
?
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.
@marcaaron Im OoO for two more days. I'll raise a PR for this after then if that's fine.
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 have a GH issue for this mentioned regression?
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.
I think #33506 could be regression from this PR.
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.
Im OoO for two more days. I'll raise a PR for this after then if that's fine.
Would you provide an update?
We can move the further discussion to #33506
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.
PR created already!
Reviewer Checklist
Screenshots/VideosWebnotification-count-empty-reports-web.mp4Mobile Web - Chromenotification-count-empty-reports-android-web-compressed.mp4Mobile Web - Safarinotification-count-empty-reports-ios-web.mp4DesktopiOSnotification-count-empty-reports-ios.mp4Androidnotification-count-empty-reports-android-compressed.mp4 |
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
@Gonals Friendly bump |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by https://github.com/Gonals in version: 1.4.9-0 🚀
|
1 similar comment
🚀 Deployed to staging by https://github.com/Gonals in version: 1.4.9-0 🚀
|
🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.4.9-5 🚀
|
As mentioned here. This caused a regression. |
Details
This PR fixes the notification count going up when an empty report is unread.
NOTE @cubuspl42 I've usedisEmpty
along withisUnread
instead ofshouldReportBeInOptionList
function because I found the former to be more simpler. The later would require us to fetch all the policies, betas and report actions before hand which I think is in-efficient and can be easily avoided by usingisEmpty
instead.Fixed Issues
$ #28536
PROPOSAL: #28536 (comment)
Tests
Offline tests
N/A
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
Screen.Recording.2023-10-22.at.2.03.19.AM.mov
iOS: Native
Screen.Recording.2023-11-17.at.1.08.47.AM.mov
iOS: mWeb Safari
Screen.Recording.2023-10-22.at.4.08.44.AM.mov
MacOS: Chrome / Safari
Screen.Recording.2023-10-22.at.1.56.09.AM.mov
MacOS: Desktop