-
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
14893: Edit message arrow up #15207
14893: Edit message arrow up #15207
Conversation
# Conflicts: # src/pages/home/report/ReportActionsView.js
shouldComponentUpdate(nextProps, nextState) { | ||
if (!_.isEqual(nextProps.reportActions, this.props.reportActions)) { | ||
this.sortedAndFilteredReportActions = this.getSortedReportActionsForDisplay(nextProps.reportActions); | ||
this.mostRecentIOUReportActionID = ReportActionsUtils.getMostRecentIOUReportActionID(nextProps.reportActions); | ||
return true; | ||
} |
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.
Is this required in here as well if we have added the logic to the ReportScreen?
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.
Yes, the mostRecentIOUReportActionID
is used just in this component and sends it down, the ReportScreen
now just is taking care of the sorting, the logic for mostRecentIOUReportActionID
isn't in ReportScreen
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.
@gedu sorry I wan not clear, I meant the big chunk of the shouldComponentUpdate
is now duplicated, do we need to check for the changes in these reportActionViews? If ReportScreen
re-renders than this rerenders too, no?
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.
ohhhh got it, yes it is true, my bad, I miss it after some merge conflicts, updating 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.
@0xmiroslav How is it looking with your review here?
src/pages/home/ReportScreen.js
Outdated
shouldComponentUpdate(nextProps) { | ||
if (!_.isEqual(nextProps.reportActions, this.props.reportActions)) { | ||
this.sortedAndFilteredReportActions = this.getSortedReportActionsForDisplay(nextProps.reportActions); | ||
|
||
return true; | ||
} |
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.
@gedu I am not very happy with moving all of this logic up which mens amore components will have to re-render because of this. Could we keep it in the ReportActionsView
and move the getSortedReportActionsForDisplay
method to ReportActionsUtils
instead since it is itself utils method.
Then we could get the sorted report actions in the ReportScreen, pass it down to the Report screen components and we can call the ReportActionsUtils.getSortedReportActionsForDisplay
from the ReportActionsView
if needed.
Is there anything I am missing?
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.
@mountiny We needed to move up so the ReportActionsView
and ReportFooter
receives the same sorted list.
I could move getSortedReportActionsForDisplay
into a utils file, but we should keep the sorting at the top.
About the rerender, it will be the same as before, because when ReportScreen
needs to rerender when reportActions
changes, was rerendering both components ReportActionsView
and ReportFooter
..., the first one to sort the actions again, and the Footer because of this arrow up feature among others props.
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 context.
@gedu Can you please resolve the merge conflict? @0xmiroslav any change you could run through the checklist today, would love to move this one on! |
# Conflicts: # src/pages/home/report/ReportActionsView.js
if (this.state.newMarkerReportActionID && _.isEmpty(lodashGet(this.props.reportActions[this.state.newMarkerReportActionID], 'message[0].html'))) { | ||
// If the report is unread, we want to check if the number of actions has decreased. If so, then it seems that one of them was deleted. In this case, if the deleted action was the | ||
// one marking the unread point, we need to recalculate which action should be the unread marker. | ||
if (ReportUtils.isUnread(this.props.report) && ReportActionsUtils.filterReportActionsForDisplay(prevProps.reportActions).length > this.props.reportActions.length) { |
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's no filterReportActionsForDisplay
function defined in ReportActionsUtils
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 was removed here c351930
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 will look at it 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.
yes, please remove here as well. App crashes right now when other sends message which makes isUnread
true
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, cool, I will update it
Reviewer Checklist
Screenshots/VideosWebweb.movDesktopdesktop.mov |
src/pages/home/ReportScreen.js
Outdated
@@ -123,6 +127,64 @@ class ReportScreen extends React.Component { | |||
Navigation.setIsReportScreenIsReady(); | |||
} | |||
|
|||
shouldComponentUpdate(nextProps) { |
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.
can we return true if this.props.report
changed?
I found regression (not refreshing) while adding/removing members.
i.e.
- Let's say 2 members (including me) in #announce room!
-This should not show Split bill on + menu. - Login same account in another platform
- Add member to this workspace on that platform
- Now back to original platform and click + and this still doesn't show Split bill
This works fine on production
This happens because report.participants
updated but not re-rendered
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.
can we return true if this.props.report changed?
I am asking this because this already does in main
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.
@0xmiroslav so this is not a regression from this PR? I think if not, we can continue here and you can file a bug report for this 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 PR causes that regression.
I am asking this because this already does in main
Here, does
means re-renders
because ReportScreen
doesn't either extend PureComponent
or use shouldComponentUpdate
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.
Actually, I don't think we need shouldComponentUpdate
in ReportScreen
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.
@gedu For what optimization did you introduce shouldComponentUpdate
in ReportScreen
?
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.
@0xmiroslav Hey, I've been looking at what you wrote and couldn't reproduce it like that, I could, following other steps, and only on web, mobile is working as expected.
Screen.Recording.2023-02-27.at.09.28.55.mp4
Let's say 2 members (including me) in #announce room!
-This should not show Split bill on + menu.
On the other hand, looking at the code, I see #announce
and #admins
always will show Split Bill on the + menu (if there are 2 members). This was working (above in the video showing the only case isn't working).
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 added the check to the reports as you suggested and is fixing the case I found, doing some round of testing and uploading fix, 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.
@gedu you opened production site on left. please run this PR on both sides.
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.
Discussed it here and we determined that it's ok to filter/sort in render()
. I think that we should do that and remove the derived state.
@0xmiroslav Any chance you could give this another go? |
I am still not convinced why we should use |
@luacmartins comments addressed |
@0xmiroslav would you mind testing again since we had changes? |
One minor concern is that we were still using unfiltered App/src/pages/home/ReportScreen.js Line 197 in a938832
So my question is is there any possibility that fetched |
src/pages/home/ReportScreen.js
Outdated
const isArchivedRoom = ReportUtils.isArchivedRoom(this.props.report); | ||
let reportClosedAction = null; | ||
if (isArchivedRoom) { | ||
reportClosedAction = ReportActionsUtils.getLastClosedReportAction(this.props.reportActions); |
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.
Thats correct, I think we should split this into two methods, we need the closed actions in it so I think we should sort it, and then remove the closed actions once we pass that to the ReporActionsView.
We should export both filtered and unfiltered |
@gedu will update this so the footer is using a selector to pull the correct closed message |
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.
LGTM and tests well. @gedu would you mind adding test steps for the archived footer scenario?
I would paste the steps given to me by @mountiny, could you help me with this? if I miss something
|
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.
@luacmartins the archived reason will be confirmed/ tested along with this PR #15474
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
return ( | ||
<> | ||
{(isArchivedRoom || hideComposer) && ( | ||
<View style={[styles.chatFooter, this.props.isSmallScreenWidth ? styles.mb5 : null]}> | ||
{isArchivedRoom && ( | ||
<ArchivedReportFooter | ||
reportClosedAction={reportClosedAction} | ||
reportClosedAction={this.props.reportClosedAction} |
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.
We don't need this anymore
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, created a PR here #15687
🚀 Deployed to staging by https://github.com/mountiny in version: 1.2.79-0 🚀
|
🚀 Deployed to production by https://github.com/roryabraham in version: 1.2.79-0 🚀
|
Minor issue we missed: App/src/pages/home/ReportScreen.js Line 89 in 10d3d52
- reportActions: {},
+ reportActions: [], |
Haha I raised this question for the usage in another page. #15207 (comment) |
reportClosedAction: { | ||
key: ({report}) => `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.reportID}`, | ||
canEvict: false, | ||
selector: ReportActionsUtils.getLastClosedReportAction, |
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 PR caused this regression #16324 because the getLastClosedReportAction
has been returning undefined
which in turn did not get swapped for the defaultProps
Details
Now
ReportScreen
is in charge to sort the messages and passing them down, this way the children receive the same data.Fixed Issues
$ #14893
PROPOSAL: #14893 (comment)
Tests
Offline tests
Same steps as before
QA Steps
Same steps as before
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
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)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.Screenshots/Videos
Web
arrowUp_chrome.mp4
Mobile Web - Chrome
arrowUp_androidChrome.mp4
Mobile Web - Safari
arrowUp_iosSafari.mp4
Desktop
arrowUp_desktop.mp4
iOS
arrowUp_ios.mp4
Android
arrowUp_android.mp4