Problem
Whenever a user starts to type a new message in Composer, the hasDraft state inside current Report object needs to be updated. The state is later used in LHN to determine if a draft indicator (pencil icon) should be displayed.
Calculations performed by the app to acquire updated hasDraft state are costly. It is caused by the fact that the hasDraft state is a property of a Report object which is then part of the entire list of reports user has access to (14k on testing account). Change of a single report causes list to be invalidated, making costly calculations of getOrderedReportIDs inside SidebarLinksData (component that resides on top of LHN) to run again.
❗ The getOrderedReportIDs calculations might take a few hundred ms, up to a few seconds depending on device and number of reports passed to the function. It is a severe execution overhead, considering how often user starts typing new message during regular conversation.
Solution
The hasDraft state can be decoupled from Report object and stored as an individual entry (or list of entries for many reports) under separate Onyx key. Such a solution should help us avoid invalidating the entire list of reports on every new message being typed, thus not triggering costly re-calculation of getOrderedReportIDs.
In Onyx, the REPORT_DRAFT_COMMENT key exists and serves similar purpose as hasDraft. Considering how hasDraft is used (to display draft indicator) it should not be an issue to re-use REPORT_DRAFT_COMMENT key for such functionality. It is mostly an implementation detail, but this way we are reducing app complexity and state redundancy.
From : @kacper-mikolajczak here
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~012397339f4d656420
- Upwork Job ID: 1777386978362355712
- Last Price Increase: 2024-04-20
Problem
Whenever a user starts to type a new message in Composer, the hasDraft state inside current Report object needs to be updated. The state is later used in LHN to determine if a draft indicator (pencil icon) should be displayed.
Calculations performed by the app to acquire updated hasDraft state are costly. It is caused by the fact that the hasDraft state is a property of a Report object which is then part of the entire list of reports user has access to (14k on testing account). Change of a single report causes list to be invalidated, making costly calculations of getOrderedReportIDs inside SidebarLinksData (component that resides on top of LHN) to run again.
❗ The getOrderedReportIDs calculations might take a few hundred ms, up to a few seconds depending on device and number of reports passed to the function. It is a severe execution overhead, considering how often user starts typing new message during regular conversation.
Solution
The hasDraft state can be decoupled from Report object and stored as an individual entry (or list of entries for many reports) under separate Onyx key. Such a solution should help us avoid invalidating the entire list of reports on every new message being typed, thus not triggering costly re-calculation of getOrderedReportIDs.
In Onyx, the REPORT_DRAFT_COMMENT key exists and serves similar purpose as hasDraft. Considering how hasDraft is used (to display draft indicator) it should not be an issue to re-use REPORT_DRAFT_COMMENT key for such functionality. It is mostly an implementation detail, but this way we are reducing app complexity and state redundancy.
From : @kacper-mikolajczak here
Upwork Automation - Do Not Edit