-
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
[HOLD for payment 2024-09-11] [$250] Opening a report from Search panel is not smooth #47724
Comments
Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new. |
@mountiny Could you please process the payment for this issue? |
Triggered auto assignment to @anmurali ( |
Job added to Upwork: https://www.upwork.com/jobs/~021833637723306135397 |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @ntdiary ( |
📣 @DylanDylann 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app! Offer link |
@anmurali can you please pay $250 to @DylanDylann for their help with this PR? Thanks! |
@anmurali Please help process payment for me |
@anmurali, @mountiny, @kacper-mikolajczak, @DylanDylann Still overdue 6 days?! Let's take care of this! |
Done. |
Problem
Transition between
Search
panel and aReport
screen is not smooth. After user selects a report, it causes:open-report-from-finder.with-timing.baseline.ios.mov
open-report-from-finder.baseline.web.mov
We would like to have app as responsive to user input as possible, while currently it creates a noticeable delay or jittering.
Testing setup:
Reproduction steps:
Search
panel (akaChatFinder
)Solution
Initial investigations show that the potential villain is a piece of
selectReport
callback inChatFinderPage
component:The
dismissModal
helper callsoriginalDismissModalWithReport
, which in turn callsgetStateFromPath
.On a regular HT account, single call to
getStateFromPath
takes about 20ms to complete on the web and about 40ms to complete on iOS.The
getStateFromPath
internally calls original getStateFromPath implementation from React Navigation, which is quite complex. It may lead to extensive computation resulting in low performance.The
Navigation.dimissModal
is called many time across the codebase (75 usages in 52 files).The implementation of this proposal would aim to improve
dimissModal
performance (also targeting additional improvements like reduction of unnecessary re-renders).Potential gains (defining an upper-bound)
In order to prove it is indeed responsible for low-quality performance during transition,
dimissModal
was replaced with regular call tonavigate
method and unnecessaryupdateSearchValue
call was removed entirely:Keep in mind, this change is not a ready solution (it changes how navigation works) and is here to define how much we could gain after implementing actual solution.
The results of proposed change are as follows:
open-report-from-finder.with-timing.upperbound.ios.mov
open-report-from-finder.upperbound.web.mov
Profiling web application shows promising results:
PR with changes: #47726
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @anmuraliThe text was updated successfully, but these errors were encountered: