-
Notifications
You must be signed in to change notification settings - Fork 3k
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 25% opacity in MoneyRequestView and TaskView #27830
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] |
enablePreviewModal | ||
/> | ||
</View> | ||
<OfflineWithFeedback pendingAction={lodashGet(transaction, 'pendingAction')}> |
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.
Maybe we can introduce...
const pendingAction = lodashGet(transaction, 'pendingAction');
const getPendingFieldAction(fieldPath) => lodashGet(transaction, fieldPath) || pendingAction;
...as right now we're contributing to the duplication in this file. What do you think?
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 it. Thanks!
@@ -538,12 +536,10 @@ function ReportActionItem(props) { | |||
} | |||
|
|||
return ( | |||
<OfflineWithFeedback pendingAction={props.action.pendingAction}> |
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.
Are you 100% confident that this is the same case? In the case of MoneyRequestView
, you observed that the removed pending action props.action.pendingAction
is equivalent to the existing conditions || lodashGet(transaction, 'pendingAction')}
. I cannot see such a pattern in the case of TaskView
.
I agree that it's great to fix another code fragment if it has an issue with the same root cause, but we're also responsible for all potential regressions we introduce.
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, we can see the report.pendingFields
and action.pendingAction
both having CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD
value when creating a task.
<OfflineWithFeedback pendingAction={lodashGet(props, 'report.pendingFields.reportName')}> |
Lines 94 to 99 in 52dc94d
pendingFields: { | |
createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, | |
reportName: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, | |
description: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, | |
managerID: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, | |
}, |
Line 2388 in 52dc94d
pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, |
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 it different from how it works in case of IOU
actions?
What I'm trying to figure out is why the pattern of checking for pendingActions is different in TaskView
and MoneyRequestView
, i.e. that in MoneyRequestView
we always check for either the outer pending action or for the field-level pending action, and in TaskView
we only check for the field-level pending actions.
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 also see the different patterns between them. When creating,
in TaskView
, we have pendingFields
in the optimistic data. But in MoneyRequestView
, we only have them when we update the fields. That's why we need to check || lodashGet(transaction, 'pendingAction')
for add
pending.
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.
Both IOU
and Task
actions have a similar set of operations, so I can't see a reason for these patterns to differ. But maybe we're exceeding the scope of this issue now...
Still, I think that if we're aware of these possible different combinations of pending actions (field-level vs the outer pending action), we should cover them in tests. Would you be able to describe the tests which ensure that the discussed ||
alternative works as expected after the PR changes?
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.
And, if possible, tests that affect tasks fields separately, demonstrating that such an alternative check is not needed, and we didn't break anything by removing the outer OfflineWithFeedback
wrapper for tasks.
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.
Tests
Scenario 1:
- Be offline.
- Requesting money.
- Open the IOU details page.
- Verify that the grayness is as usual (50%).
- Be online.
- Verify that there is no grayness in the content.
- Be offline.
- Update Amount, Description, Date, Merchant.
- Verify that the grayness is as usual (50%).
- Be online.
- Verify that there is no grayness in the content.
Scenario 2:
- Be offline.
- Creating a task.
- Open the task details page.
- Verify that the grayness is as usual (50%).
- Be online.
- Verify that there is no grayness in the content.
- Be offline.
- Update Title, Description.
- Verify that the grayness is as usual (50%).
- Be online.
- Verify that there is no grayness in the content.
What do you think about it?
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.
Looks 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.
I updated the steps and videos.
Please merge |
Reviewer Checklist
Screenshots/VideosWebgray-opacity-web.mp4Mobile Web - Chromegray-opacity-android-web-compressed.mp4Mobile Web - Safarigray-opacity-ios-web.mp4DesktopiOSgray-opacity-ios.mp4Androidgray-opacity-android-compressed.mp4 |
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
✋ 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/stitesExpensify in version: 1.3.75-0 🚀
|
🚀 Deployed to production by https://github.com/mountiny in version: 1.3.75-12 🚀
|
🚀 Deployed to staging by https://github.com/stitesExpensify in version: 1.3.76-0 🚀
|
🚀 Deployed to production by https://github.com/mountiny in version: 1.3.76-6 🚀
|
enablePreviewModal | ||
/> | ||
</View> | ||
<OfflineWithFeedback pendingAction={pendingAction}> |
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.
Passing the pendingAction
value directly as pendingAction
to ReportActionItemImage causes the opacity to reduce to 0.25 when parentReportAction.pendingAction is set to 'add'.
Instead, we should pass the specific keys for pendingAction—pendingAction.waypoints and waypoints.receipt.
More context can be found in the selected proposal: #52123 (comment)
Details
MoneyRequestView
andTaskView
content are wrapped by twoOfflineWithFeedback
. When requesting money or creating a task offline, its content has 25% opacity rather than 50% opacity.Fixed Issues
$ #26235
PROPOSAL: #26235 (comment)
Tests
Scenario 1:
Scenario 2:
Offline tests
Same as tests
QA Steps
Same as tests
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.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/Videos
Web
Screen.Recording.2023-09-21.at.6.14.13.PM.mp4
Screen.Recording.2023-09-21.at.6.46.05.PM.mp4
Mobile Web - Safari
Screen.Recording.2023-09-21.at.7.57.20.PM.mp4
Screen.Recording.2023-09-21.at.7.35.18.PM.mp4
Mobile Web - Chrome
Screen.Recording.2023-09-21.at.7.00.36.PM.mp4
Screen.Recording.2023-09-21.at.7.02.39.PM.mp4
Desktop
Screen.Recording.2023-09-21.at.6.26.23.PM.mp4
Screen.Recording.2023-09-21.at.6.48.44.PM.mp4
iOS
Screen.Recording.2023-09-21.at.7.08.53.PM.mp4
Screen.Recording.2023-09-21.at.7.12.41.PM.mp4
Android
Screen.Recording.2023-09-21.at.7.05.19.PM.mp4
Screen.Recording.2023-09-21.at.8.02.49.PM.mp4