-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[$500] IOU - Category is displayed in delay in employee workspace #37768
Comments
Triggered auto assignment to @lschurr ( |
@lschurr FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors |
This is part of wave-collect but I'll file it under wave 6 for now. Tagging @greg-schroeder who is sorting through these. |
Sorry, looks like have now agreed to close out the Wave 6 project, so we'll get it into the new one soon |
Job added to Upwork: https://www.upwork.com/jobs/~01bb370ed42a61f34d |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @fedirjh ( |
ProposalPlease re-state the problem that we are trying to solve in this issue.We have two screens here.
When we change the value of the category, it shows up delayed in the confirmation screen we immediately navigate back to. What is the root cause of that problem?When we go to the Category screen, we save the category AND navigate back to the confirmation screen in the same step. This causes a race condition between the Modal Stack Navigator and the time it takes to update the Onyx store and refetch the newly updated category to display. Important note: The delay time is not very noticeable on faster laptops, but on slower devices, it can be pretty noticeable, as in the original post. What changes do you think we should make in order to solve the problem?In order to immediately reflect the category, we should not use Navigate.goBack like we are doing here But instead use
We would update IOURequestStepConfirmation ( the parent here with the outdated category value) to check if the category is in its route params and use that value; otherwise, use the transaction category as a fallback for all existing flows. These parameters from navigation allow us to immediately utilize the updated value rather than waiting for it! And it doesn't impact the user flow. What alternative solutions did you explore? (Optional) |
@fedirjh could you review the proposal? |
@jeremy-croff Could you please elaborate on this? can you explain this race condition? |
It's the animation transition between the two screens, how the card transitions from left to right as you click save category. If the animation for navigation was super slow. i.e. 1 second, most pc's would have already updated the prop of the selected category. If you slow down your CPU in the browser, you extend the time at which the stale category is shown. Check the video timestamp at 27 seconds. |
I think this is due to Onyx and not the animation. I recall that we had a similar bug where the animation was not smooth after changing the merchant, it was reported here #31193. |
I think we are on the same page, I just called it out as a race condition between both in regards of the user experience. But my solution works around this by allowing the updated data to be passed as params instead of having to wait for onyx. I don't think we can realistically expect to write and retrieve to a cache outside of the components' lifecycle to be reflected instantly ever. And I did not want to impact the customer experience by adding in a middle step or something that would delay the navigation to mask the onyx persistence. |
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
Any update @fedirjh? |
@jeremy-croff I appreciate your effort to address the issue, but I have concerns about the suggested workaround. While passing updated data as parameters may temporarily fix the issue, it doesn't address the root cause. In the past, we used a similar approach in this flow. However, we've since moved to using I believe it's crucial to investigate and address the root cause, which appears to be related to I suggest we focus our efforts on identifying and resolving the
@lschurr We are still awaiting for proposals, We could probably pass this issue to Agency expert. |
Thanks! I'll post in an agency room today. |
@fedirjh 2024-03-19_21-53-13.mp4 |
@jeremy-croff I think this pattern was implemented in this PR to fix another issue, The loading indicator prevents the component from rendering with the wrong currency, until the correct currency is set. |
Is that not the same problem for a different field? |
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
@jeremy-croff It seems that the loading view will be removed in this PR: |
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
We are still awaiting new proposals. |
I asked for help from Callstack here - https://expensify.slack.com/archives/C03UK30EA1Z/p1711987304872579 |
Hi! I’m Pedro Guerreiro from Callstack - expert contributor group. I’d like to work on this task! |
📣 @fedirjh 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app! |
Issue not reproducible during KI retests. (First week) |
Hi, I wasn't able to reproduce this issue 😅 Could this happen in slow internet connections? |
I am unable to reproduce as well. It seems like the recent |
Great! Going to close since this is no longer an issue. |
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.47
Reproducible in staging?: Y
Reproducible in production?: Y
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:
Expected Result:
Category must be displayed without delay in employee workspace
Actual Result:
Category is displayed in delay in employee workspace
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
Bug6402940_1709652465108.empf.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: