-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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 workspace avatar it not updated #19750
Conversation
@iwiznia @abdulrahuman5196 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] |
@iwiznia @abdulrahuman5196 hey, I wanna discuss about this. |
@iwiznia @hungvu193 So @iwiznia wanted to check since you had approved, is the policy.avatar more reliable? Since its basically the original proposal instead of passing icons we are using policy.avatar and introducing a prop just to fix this issue. That's why we went with the alternate proposal. @hungvu193 Let me know your thoughts as well. |
Ah damn, sorry, yes, I agree |
Thank you. @hungvu193 could you kindly update the PR with the original approved proposal? |
Yeah, but actually if we want to compare const icons = ReportUtils.getIcons(this.props.report, this.props.personalDetails);
const nextIcons = ReportUtils.getIcons(nextProps.report, nextProps.personalDetails); ![]() |
you don't need to pass it as props from parent view. You can directly access it from onyx like in the ReportActionItem App/src/pages/home/report/ReportActionItem.js Line 443 in d06d032
|
How about my second concern? I realized if we calculated |
Ok got it. So the main concern is if the policy information gets changed we won't reload since we don't get the information as its not a prop of ReportActionsView. So anyways regardless of I am aligned with the current approach based on the above. So I think if in future anyone wants more function they can use always use ReportUtils.getIcons and it would be working fine since we already have policy as props. |
Will start testing this out then. |
@@ -340,6 +342,7 @@ class ReportScreen extends React.Component { | |||
isComposerFullSize={this.props.isComposerFullSize} | |||
isDrawerOpen={this.props.isDrawerOpen} | |||
parentViewHeight={this.state.skeletonViewContainerHeight} | |||
policy={policy} |
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 pass the policies directly and have the filter in ReportActionsView similar to how MoneyRequestHeader is doing?
App/src/pages/home/ReportScreen.js
Line 297 in 619a529
policies={this.props.policies} |
The reason I saying is, for normal chats and group chats the policy would be undefined and we would be passing a undefined value, which won't be a good code practice. With the proposed way it will be in sync with existing code as well.
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.
Sure @abdulrahuman5196
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.
Updated @abdulrahuman5196 !
const policy = this.props.policies[`${ONYXKEYS.COLLECTION.POLICY}${this.props.report.policyID}`]; | ||
const nextPolicy = nextProps.policies[`${ONYXKEYS.COLLECTION.POLICY}${nextProps.report.policyID}`]; | ||
|
||
if (!_.isEqual(policy, nextPolicy)) { |
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.
Shouldn't avatar equality be enough? Policy will have other values for which we might not want to reload.
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.
yeah, you're right, we can avoid unnecessary comparing. @abdulrahuman5196
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 updated and tested it as well.
@@ -120,6 +127,13 @@ class ReportActionsView extends React.Component { | |||
} | |||
|
|||
shouldComponentUpdate(nextProps, nextState) { | |||
const policy = this.props.policies[`${ONYXKEYS.COLLECTION.POLICY}${this.props.report.policyID}`]; |
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.
@hungvu193 One change. This should be checked only before the icons equality check.
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionsView.js#L171
I don't think this is of high priority to be checked for equality first. Can we move this check just before the icons equality check?
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.
Nice catch. Thank you @abdulrahuman5196 . I've updated the 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.
I don't think there is use in fetching the policy before and checking its equality on lower part. This policy is not used anywhere else.
can we move the policy and nextPolicy lines before the equality check?
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.
// other condition
const policy = this.props.policies[`${ONYXKEYS.COLLECTION.POLICY}${this.props.report.policyID}`];
const nextPolicy = nextProps.policies[`${ONYXKEYS.COLLECTION.POLICY}${nextProps.report.policyID}`];
if (lodashGet(policy, 'avatar') !== lodashGet(nextPolicy, 'avatar')) {
return true;
}
Somethings like this right? So we can avoid to calculate policy every time.
@abdulrahuman5196
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.
updated! @abdulrahuman5196
@iwiznia |
🤔 so the question is if we fix the name problems here too or just the avatar? |
Yes. @iwiznia |
Ah, ok. If we are touching the same places and makes sense to group the changes, then lets? |
Ok then @hungvu193 could you fix this? #19750 (comment) |
@abdulrahuman5196 this is actually another issue. Problem came from here: App/src/components/ReportActionItem/ReportPreview.js Lines 118 to 121 in d8b1d84
The payer name is already updated, but we are displaying it only when we couldn't get the html from message, that's why even you reloaded the page, you still saw that the workspace name is not updated. I'm happy to open another PR to fix this issue. cc @iwiznia |
@hungvu193 The issue #19847 which we added here required the fix for both the workspace name in created message header and IOU message.
I wouldn't say it as different issue. I don't think we should only solve half the other issue we agreed to fix it as part of this pr |
@iwiznia I think we might be bugging you. 😶🌫️ . But wanted to close the loop and avoid future churns. What do you think of this #19750 (comment)?
The 2nd sub-issue isn't in the code place where our current PR originally focused. - #19750 (comment). It could even need a separate proposal review. That was the original reason i thought to not merge the issues since it would require more changes at different place - #19750 (comment) So the options here is
My alignment was either to fix the name issue totally or totally not(1 and 3). But I am also fine with option 2, to solve as much as possible here and have a separate review on IOU workspace name not updated - #19847 (I think @hungvu193's alignment is on this option #19750 (comment)). Kindly let us know of the path forward. |
2 sounds best to me. We have a proposal here to solve this issue and that other subissue and they are fixed in the same place. Sounds good? |
Sure sounds good. Will start reviewing on this basis |
Sounds good to me too. I'll update my proposal at related issue. |
@hungvu193 Could you kindly include the tests to reflect the workspace name change as well? And for offline test, Shouldn't it be |
Reviewer Checklist
Screenshots/VideosWebUntitled.49.mp4Mobile Web - ChromeUntitled.47.mp4Mobile Web - SafariUntitled.51.mp4DesktopUntitled.48.mp4iOSUntitled.50.mp4AndroidUntitled.mp4 |
Thanks for pointing that out @abdulrahuman5196 . I've just updated the steps. |
@@ -41,6 +42,7 @@ const propTypes = { | |||
...windowDimensionsPropTypes, | |||
...withDrawerPropTypes, | |||
...withLocalizePropTypes, | |||
...policyPropTypes, |
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 think we can use policyPropTypes
because it has policyMemberList
which we don't pass now.
Can we use the way you previously had? @hungvu193
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.
That's ok. I've just updated it @abdulrahuman5196
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.
Changes looks good and works well. Reviewers Checklist is also complete.
@iwiznia All yours.
✋ 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/iwiznia in version: 1.3.24-0 🚀
|
🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.24-5 🚀
|
🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.24-5 🚀
|
Details
fix workspace avatar and workspace name are not updated
Fixed Issues
$ #19550
PROPOSAL: #19550 (comment)
Tests
Offline tests
Same as Tests.
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
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.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
Web
Screen.Recording.2023-05-30.at.00.20.21.mov
Mobile Web - Chrome
Screen.Recording.2023-05-30.at.00.31.09.mov
Mobile Web - Safari
Screen.Recording.2023-05-30.at.00.27.52.mov
Desktop
Screen.Recording.2023-05-30.at.00.26.02.mov
iOS
Screen.Recording.2023-05-30.at.00.23.00.mov
Android
Screen.Recording.2023-05-30.at.00.24.46.mov