14893: Edit message arrow up - #15207
Conversation
# Conflicts: # src/pages/home/report/ReportActionsView.js
|
@mountiny @0xmiroslav One of you needs to 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] |
| 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.
Is this required in here as well if we have added the logic to the ReportScreen?
There was a problem hiding this comment.
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.
@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.
ohhhh got it, yes it is true, my bad, I miss it after some merge conflicts, updating PR
mountiny
left a comment
There was a problem hiding this comment.
@0xmiroslav How is it looking with your review here?
| shouldComponentUpdate(nextProps) { | ||
| if (!_.isEqual(nextProps.reportActions, this.props.reportActions)) { | ||
| this.sortedAndFilteredReportActions = this.getSortedReportActionsForDisplay(nextProps.reportActions); | ||
|
|
||
| return true; | ||
| } |
There was a problem hiding this comment.
@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.
@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.
|
@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.
There's no filterReportActionsForDisplay function defined in ReportActionsUtils
There was a problem hiding this comment.
I will look at it thanks
There was a problem hiding this comment.
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.
ok, cool, I will update it
Reviewer Checklist
Screenshots/VideosWebweb.movDesktopdesktop.mov |
| Navigation.setIsReportScreenIsReady(); | ||
| } | ||
|
|
||
| shouldComponentUpdate(nextProps) { |
There was a problem hiding this comment.
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.
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.
@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.
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.
Actually, I don't think we need shouldComponentUpdate in ReportScreen
There was a problem hiding this comment.
@gedu For what optimization did you introduce shouldComponentUpdate in ReportScreen?
There was a problem hiding this comment.
@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.
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.
@gedu you opened production site on left. please run this PR on both sides.
There was a problem hiding this comment.
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 |
| 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.
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 |
luacmartins
left a comment
There was a problem hiding this comment.
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
|
mountiny
left a comment
There was a problem hiding this comment.
@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. |
| {isArchivedRoom && ( | ||
| <ArchivedReportFooter | ||
| reportClosedAction={reportClosedAction} | ||
| reportClosedAction={this.props.reportClosedAction} |
There was a problem hiding this comment.
We don't need this anymore
|
🚀 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.
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
ReportScreenis 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 Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)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.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