Design Doc: https://docs.google.com/document/d/1Aw3gB8ksT5b1xGBtoAKSPR5pcBXHh9yjmRWv8GGdbXM/edit
Proposal:
Move manual merging to LocalForage, since in SQLiteStorage this is already done with JSON_PATCH
Problem:
Onyx is our low level state management layer. We need this layer to be as fast as possible on native devices as everything the user sees and does is driven by this layer. At the moment when data is merged into Onyx we perform a series of inefficient steps:
- In the past we had to solve a race condition related to our asynchronous storage providers (AsyncStorage and LocalForage) when making updates in a single tick of the event loop. To solve this, we had to queue partial updates into a batch, get the most up to date data from storage, and then merge the queue into the existing data and replace the entire key.
- On native, this requires that we potentially pull large objects out of device storage and send them across React Native bridge.
- We must also serialize and deserialize this data which can be an expensive task to perform especially on native.
Solution:
To properly separate logic for native vs. web, we should have different merge logic for each data provider. My solution would be to move the manual merge to LocalForage.js’s merge function and keep JSON_PATCH in case of conflicts in SQLiteStorage.js
Tasks:
Design Doc: https://docs.google.com/document/d/1Aw3gB8ksT5b1xGBtoAKSPR5pcBXHh9yjmRWv8GGdbXM/edit
Proposal:
Move manual merging to LocalForage, since in SQLiteStorage this is already done with JSON_PATCH
Problem:
Onyx is our low level state management layer. We need this layer to be as fast as possible on native devices as everything the user sees and does is driven by this layer. At the moment when data is merged into Onyx we perform a series of inefficient steps:
Solution:
To properly separate logic for native vs. web, we should have different merge logic for each data provider. My solution would be to move the manual merge to LocalForage.js’s merge function and keep JSON_PATCH in case of conflicts in SQLiteStorage.js
Tasks:
strategy@expensify.comwith Proposalstrategy@expensify.com(same email chain as before) with link to Design Doc#expensify-open-sourceto discuss any necessary details in public before filling out the High-level of proposed solution sectionstategy@expensify.comagain with links to the doc and pre-design conversation in SlackDesignDocReviewlabel to get the High-level of proposed solution section reviewed#expensify-open-sourceto ask for engineering feedback on the technical solution.DesignDocReviewstrategy@expensify.comone last time to let them know the Design Doc is moving into the implementation phase