Closed mountiny closed 1 month ago
Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new.
Triggered auto assignment to @zanyrenney (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Job added to Upwork: https://www.upwork.com/jobs/~0109e0b5642eb1863c
Triggered auto assignment to Contributor-plus team member for initial proposal review - @ikevin127 (External
)
Hey, I’m from Software Mansion and I will take care of this issue :)
📣 @ikevin127 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!
A discussed in Slack, please try to split this up to two PRs
⚠️ Looks like this issue was linked to a Deploy Blocker here
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
⚠️ Automation failed here -> this should be on [HOLD for Payment 2024-07-22] according to today's production deploy from https://github.com/Expensify/App/pull/44948#issuecomment-2229340753 and https://github.com/Expensify/App/pull/44955#issuecomment-2229341167.
I'm the only one requiring payment here for reviewing PRs https://github.com/Expensify/App/pull/44948 and https://github.com/Expensify/App/pull/44955. Additionally, 1 regression was reported above, therefore bounty payment shoud be adjusted to match that - waiting for regression confirmation from @mountiny.
cc @zanyrenney
$375 to @ikevin127 for reviewing 2 PRs and deducing 50% of one bounty for the regression
@zanyrenney Friendly bump for payments, as I noticed this doensn't have the Daily
label which could cause delays.
payment summary
@ikevin127 - paid $375 via upwork @kosmydel - internal contractor - not paid incrementally.
Thanks!
Problem
The Profiler indicates that the ReportScreen render time gets re-rendered dozens of times, with each re-rendering taking an average of 599.8ms.
The most current problems are with this hook:
In this PR we’ve introduced the above hook and there might be several problems with it:
lastAccessedReportID
in each re-render, however, we only require it in one particular scenario: when theroute.params.reportID
is empty,useLastAccessedReportID
hook is heavy, due to the poor performance of theReportUtils.findLastAccessedReport
function. This issue existed before the introduction of the PR mentioned.Solution
Ad 1. We should calculate the lastAccessedReportID only when needed, that means only once, and only when route.params.reportID is empty (code). This value is used to determine which chat we should show to the user when the user accesses the website without reportID in the URL. POC
Ad 2. After diving deep into the code I’ve discovered that we sort a whole array of reports just to get one, the most recent, report. We can replace this sort with
lodashMaxBy
, as we do not (from my analysis) need to sort all reports (needs confirmation). POCcc @kosmydel
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @zanyrenney