Optimize drafts reports in useReportIDs to Reduce Renders #54094
Labels
AutoAssignerNewDotQuality
Used to assign quality issues to engineers
Bug
Something is broken. Auto assigns a BugZero manager.
Daily
KSv2
Background
The useReportIDs hook is responsible for managing the list of report IDs displayed in the sidebar. It uses a combination of useCallback and useMemo to optimize the generation of the ordered report IDs and the context value. However, the current implementation includes reportsDrafts as a dependency in the getOrderedReportIDs callback.
When a draft is updated (e.g., a user types or edits a message), the reportsDrafts changes, causing the getOrderedReportIDs callback to update. This triggers the re-execution of other hooks, including the expensive SidebarUtils.getOrderedReportIDs function, which recalculates the ordered report IDs. This recalculation happens even when the draft content changes but the number of drafts (reportsDrafts) remains the same.
Problem
The useReportIDs hook currently updates the draft state every time content of the draft message is being changed.
Solution
It is super important optimize the useReportIDs hook by changing the dependency on the getOrderedReportIDs callback - from the draft content itself to the number of active drafts. This ensures that renders are only triggered when the draft count changes, not when the content of the draft is updated.
○ Replace the reportsDrafts with draftAmount as a dependency to the useCallback function in the useReportIDs hook.
Comparison
● Current Implementation: ±11,455.4 ms: Total time spent rendering ReportIDsContextProvider due to frequent updates triggered by draft changes, causing unnecessary recalculations.
● Updated Total: ±4,410.8 ms: Total time after optimizing useReportIDs to update only when the draft count changes, reducing unnecessary renders.
● 7,044.6 ms saved: Significant reduction in render time by avoiding redundant recalculations.
Slack: https://expensify.slack.com/archives/C05LX9D6E07/p1733994811786719
Issue Owner
Current Issue Owner: @geduThe text was updated successfully, but these errors were encountered: