Repository navigation
IOU - There is a delay in displaying the members involved in a split bill #34271
Description
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 1.4.24-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:
- Open a group chat
- Go to the Split bill
- Enter the amount and proceed next
- Notice members section displayed after a second
Expected Result:
There should not be delay in displaying the members involved in a split bill
Actual Result:
There is a delay in displaying the members involved in a split bill
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
Activity
github-actions commentedon Jan 10, 2024
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
melvin-bot commentedon Jan 10, 2024
Triggered auto assignment to @amyevans (
Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.dukenv0307 commentedon Jan 10, 2024
Proposal
Please re-state the problem that we are trying to solve in this issue.
"To" field shows up late on confirmation page
What is the root cause of that problem?
We initialize the data when the component is mounted and wrap it into
InteractionManager.runAfterInteractionswhich makes the delay.App/src/components/OptionsSelector/BaseOptionsSelector.js
Line 132 in 55746c7
What changes do you think we should make in order to solve the problem?
I think we should add an extra props like
shouldInitialAfterInteractionwith the default value asfalseWe will only initialize after the interaction If
shouldInitialAfterInteractionis trueApp/src/components/OptionsSelector/BaseOptionsSelector.js
Line 132 in 55746c7
We will pass it as true in some pages which we want the transaction smoother like
SearchPage,StartChat, ...What alternative solutions did you explore? (Optional)
We can change the default value of
shouldInitialAfterInteractiontotrueand add this asfalsein confirm page and others which we need.Or we can only wrap the interaction if the platform is not web and desktop.
situchan commentedon Jan 10, 2024
fixed in #34267 which is being CP'ed
amyevans commentedon Jan 10, 2024
Perfect, will keep an eye on the build
amyevans commentedon Jan 10, 2024
@lanitochka17 could you retest on the latest staging build please? (
1.4.24-1)amyevans commentedon Jan 10, 2024
Asked in #qa as well for a retest. I can't repro but would love some additional confirmation 😄
mountiny commentedon Jan 11, 2024
Reverted #33596 (comment) so we can close now
amyevans commentedon Jan 11, 2024
Thanks! To close the loop QA also confirmed it's fixed after a retest: https://expensify.slack.com/archives/C9YU7BX5M/p1704936138065639?thread_ts=1704924266.002129&cid=C9YU7BX5M