Fix: RHN lag when close#45691
Conversation
|
@allgandalf 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] |
|
@truph01 can you please update videos on all platforms , our guidelines do state that, and also the video for desktop as well as safari are the same can you check once and upload platform specific please 🙏
|
|
Sure. I am updating it. Just ping you once done |
|
@allgandalf I updated all the videos |
|
waiting for comments to be addressed |
|
Confirmed the issue is reproducible, reviewing now |
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2024-08-19.at.11.55.13.AM.movAndroid: mWeb ChromeScreen.Recording.2024-08-19.at.11.53.20.AM.moviOS: NativeScreen.Recording.2024-08-19.at.12.02.55.PM.moviOS: mWeb SafariScreen.Recording.2024-08-19.at.11.40.59.AM.movMacOS: Chrome / SafariScreen.Recording.2024-08-19.at.11.34.21.AM.movMacOS: DesktopScreen.Recording.2024-08-19.at.11.37.15.AM.mov |
|
@truph01 , there is noticeble lag on desktop, can you please take a look: Screen.Recording.2024-07-31.at.11.16.24.AM.mov |
@allgandalf I think you are referring to the "delay" when closing modal, right? If so, It is because of this code: |
|
@allgandalf Bump to review my comment above |
That shouldn't be the case right? the actual issue says that things should be smooth and no dealy/lag |
|
@allgandalf In my opinion, the |
|
@allgandalf I can reproduce the janky animation in desktop with the High Traffic Account. My solution to fix it is updating: App/src/pages/tasks/TaskAssigneeSelectorModal.tsx Lines 170 to 182 in 8d11d0b to: + Navigation.dismissModal(report.reportID);
+ InteractionManager.runAfterInteractions(() => {
if (option.accountID === report.managerID) {
return;
}
const assigneeChatReport = TaskActions.setAssigneeValue(
option?.login ?? '',
option?.accountID ?? -1,
report.reportID,
undefined, // passing null as report because for editing task the report will be task details report page not the actual report where task was created
OptionsListUtils.isCurrentUser({...option, accountID: option?.accountID ?? -1, login: option?.login ?? ''}),
);
// Pass through the selected assignee
TaskActions.editTaskAssignee(report, session?.accountID ?? -1, option?.login ?? '', option?.accountID, assigneeChatReport);
+ });
- Navigation.dismissModal(report.reportID);I tested and it works well. What do you think? |
|
@MonilBhavsar , what do you think? should we fix this, or is that expected? |
When choosing any option, the modal is closed with a delay time (200ms), it is our expected. When the modal is closing, there is a janky/lag in transition animation, it is the main bug we need to fix in this PR. |
Yes, i think we should fix it |
|
@allgandalf Any updates on it? Can you check my suggested solution ? Thanks |
|
You can apply that @truph01 , lets see how that works |
|
@allgandalf I updated PR. Please help review it again |
|
@allgandalf Do you have any updates on this PR? |
|
@truph01 , here is a regression coming here: our PR: Screen.Recording.2024-08-15.at.10.35.58.AM.movStaging: Screen.Recording.2024-08-15.at.10.36.14.AM.movThere is a delay of 1 second, the assignee doesn't change instantly, @MonilBhavsar we do count that as a regression right? @truph01 do you think you can fix that? |
|
This fruit has been hanging for too long now, lets work together and get this PR to staging 🚀 |
That delay is expected with the current changes in the PR.
At the moment, I don't have a solution that combines the advantages of both approaches in staging and in this PR. |
|
@MonilBhavsar Please help check C+ comment and my comment when you have a chance. Thanks |
|
Yes, it does seem like a regression. Back to the issue, the root cause was both processes happening at the same time and there was a lag. So can we change the order here - Onyx update first and navigation then |
|
@allgandalf I updated PR to make sure the onyx data is merged successfully before navigating. It is my alternative solution in proposal. Please help review PR again. |
|
@truph01 thanks! |
| TaskActions.setAssigneeValue( | ||
| option?.login ?? '', | ||
| option.accountID, | ||
| option.accountID ?? -1, |
There was a problem hiding this comment.
is account id a string or number ? if it is a number then we fallback to 0 for numbers, can you help me confirm @truph01 ?
There was a problem hiding this comment.
@allgandalf the accountID is number. If it is number, I think we should fallback to -1 as we did in other logics.
There was a problem hiding this comment.
is it, the other day i was reviewing a PR and they fallback to 0:
#46931 (comment)
There was a problem hiding this comment.
I just refer to our contributor style docs:
https://github.com/Expensify/App/blob/main/contributingGuides/STYLE.md#default-value-for-inexistent-ids
There was a problem hiding this comment.
Yeah that is because in the example reportID is a string:
Lines 140 to 141 in 9940e99
and as you said:
@allgandalf the accountID is number.
There was a problem hiding this comment.
I think that the fallback -1 should be applied regardless the id is number or string since I just checked this PR, we are using -1 as number, for example https://github.com/Expensify/App/pull/42634/files#diff-ea38863732cfd28f820d12c5b3f2633a8799cb797929c39af675b6a11452e9ee
There was a problem hiding this comment.
Confirmed on slack that 0 is a valid account id
There was a problem hiding this comment.
If -1 is a valid account id, then we should fall back to 0, right?
There was a problem hiding this comment.
sorry, it is the other way around
allgandalf
left a comment
There was a problem hiding this comment.
Lets get this shipped 🚀
|
🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.22-0 🚀
|
|
🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.22-1 🚀
|
|
🚀 Deployed to production by https://github.com/chiragsalian in version: 9.0.22-9 🚀
|

Details
Fixed Issues
$ #43410
PROPOSAL: #43410 (comment)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Screen.Recording.2024-07-18.at.23.30.49.mov
Android: mWeb Chrome
Screen.Recording.2024-07-18.at.23.28.23.mov
iOS: Native
Screen.Recording.2024-07-18.at.23.38.40.mov
iOS: mWeb Safari
Screen.Recording.2024-07-18.at.23.26.51.mov
MacOS: Chrome / Safari
Screen.Recording.2024-07-18.at.23.25.12.mov
MacOS: Desktop
Screen.Recording.2024-07-18.at.23.26.07.mov