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.
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
Add notification preference for all the reports and update the design for the group chats #28200
Add notification preference for all the reports and update the design for the group chats #28200
Changes from 7 commits
32df987
78bcb7e
d122a0d
c5946e3
cf82041
083c924
994140d
5910aa9
d4f11fa
3df0e95
89fc4ae
5b731c0
491e044
f050e20
d21f21c
3c880c6
79560ff
626ec91
4417b5c
b8a66ed
e2ee8df
ac77a36
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm having second thoughts about this. What was the reason for adding the second
withOnyx
call? And could we fix this by just adding aprivateNotesReportID
to the user's session key maybe?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 are dependent on the value of
session
props to see if the notes belong to the current user. We have a few use cases with similar patterns.Users can have multiple private notes. On each chat, they have a different note. To say, private notes are report rNVPs characterized by the user's accountID(so each participant) can have their notes on chats they belong to.
So do you think we can still add the key to the user's session?
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 honestly didn't pay attention to the second call of
withOnyx
.From #27463 we created a rule to prevent multiple uses
withOnyx
, it's better we avoid it.I know that having a report key listener here is to re-render the page and show the latest value for the preference menu item. So I think it's better we find another way to do this.
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.
Hmm okay it sounds like these private notes reportIDs should probably go in it's own key/collection. Something like
privateNotesReportID_{accountID}
though we should probably take that to #engi-chat to get second opinions.In the meantime, did we really need to change the way we load this to begin with? What was wrong with the logic we had before here?
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.
Yeah, I did bring that up in the design doc but we went with adding it as a key to report object. See here: https://docs.google.com/document/d/1StLBx3Y6yJsZp54rHMu-mGo20pUt1niV6Y0MPNDR6A4/edit?disco=AAAA0B4ClCw
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.
If I'm understanding correctly, It sounds like these private note reports are tied to accounts not reports right? If so I think the concerns in that thread were misguided 😄. Ideally we shouldn't have to load a report just to get the privateNotesReportID for an account. Either way, I guess there's no problem with the revert so we can probably just :donothing:.
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.
Each user can have private notes on all the chat reports they are part of. If I have access to reports 1 and 2, then I can have private notes on both report 1 and report 2. We also discussed bringing public notes, so in that case, they won't be tied to accounts but only to the reports.
💯 agree with this. But it looks like we do that for a couple more things, no? like lastReadTime and stuff? Since there are no major concerns with how we are handling the data, I too will just stick with :donothing: for now.
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.
Now I know why I made that change
#28200 (review)
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.
Not sure I understand that comment, but it sounds like there's urgency behind this so I won't be a blocker. However, can we create a follow up issue to clean this up and remove the need for a second Onyx subscription? I'm not sure exactly how it should be cleaned up but it definitely doesn't need to be like this. Thanks!
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.
Let me just reiterate the problem statement so it's clear for you.
We have now added the notification preference option on the profile page. The challenge is that the profile page doesn't subscribe to any report by default. Instead, it depends on the user profile you've navigated to. It's not just about fetching the chat report between you and another user; the ProfilePage needs to actively subscribe to it. This subscription is crucial because when you update your notification preference, the component should re-render and display the updated notification preference from the report.
This was first reported here: #28200 (comment) and we did figure out a better solution for this here #28200 (comment), which involved creating a separate component for the notification preference. This new component would subscribe to the DM chat report using Onyx, ensuring that when you update your notification preference, it automatically re-renders and displays the updated data.
We agreed that it might be overkill #28200 (comment) so we just so we opted to stick with a double Onyx call for now. A future solution is to create a dedicated notification preference page component, which can be reused throughout the entire application as needed.
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 caused regression when user opens new user profile link first time.
This happens because
report_
returning all reports.We should fix this by setting
report_0
orreport_null
ornull
Right now, app crashes and will be a deploy blocker soon
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.
raised PR for the quick fix
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.
You haven't taken into account the dependency of
getChatByParticipants
on reports which caused #35654There 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.
Is there reason for removing
!shouldDisableSettings ||
condition here?This caused regression - #29321
Edit: Ah I think I got answer here
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.
After enabling settings for all the reports and revealing access to the notification preference page. We had to test the offline behavior for the newly enabled reports. Coming from #29334 this caused a regression where the creation of a new task missed the optimistic prop
notificationPreference
.