If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
What performance issue do we need to solve?
We are trying to make Onyx more performant by default. Right now, onyx always starts in a loading state, then collects all the
requested keys and sets them to the component state. This is often times inefficient as all the data is already available in a cache which we can read synchronously.
For exact technical details see: Expensify/react-native-onyx#269
What is the impact of this on end-users?
- Unnecessary loading states: We often start by default in a loading state, although we could show the content right away. Showing the content directly provides better UX
- Performance impacts due to a lot of re-renders: Due to this architecture a component re-renders a lot until it reached its final loaded state. This comes with a performance cost creating janky transitions to screens.
List any benchmarks that show the severity of the issue
See: Expensify/react-native-onyx#269
Proposed solution (if any)
See: Expensify/react-native-onyx#269
Once we have the onyx changes in place we need to update onyx in the app and adjust a few screens to work correctly. Some screens are build with the assumption that we will always start in a loading state.
We will start by adjusting the ReportScreen. The following adjustments need to be made (as discussed here):
- Defer the loading of new chat messages to the next batch, so it doesn’t block the initial rendering by changing a state variable on the report.
- There was recently a
firstRenderRef introduced, which delays the real rendering of the report screen after it has been mounted. We want to get rid of it to show the available content right away.
List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)
See: Expensify/react-native-onyx#269
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: x
Reproducible in staging?: yes
Reproducible in production?: yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
**Issue reported by: @hannojg **
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1688580518417739
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
What performance issue do we need to solve?
We are trying to make Onyx more performant by default. Right now, onyx always starts in a loading state, then collects all the
requested keys and sets them to the component state. This is often times inefficient as all the data is already available in a cache which we can read synchronously.
For exact technical details see: Expensify/react-native-onyx#269
What is the impact of this on end-users?
List any benchmarks that show the severity of the issue
See: Expensify/react-native-onyx#269
Proposed solution (if any)
See: Expensify/react-native-onyx#269
Once we have the onyx changes in place we need to update onyx in the app and adjust a few screens to work correctly. Some screens are build with the assumption that we will always start in a loading state.
We will start by adjusting the
ReportScreen. The following adjustments need to be made (as discussed here):firstRenderRefintroduced, which delays the real rendering of the report screen after it has been mounted. We want to get rid of it to show the available content right away.List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)
See: Expensify/react-native-onyx#269
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: x
Reproducible in staging?: yes
Reproducible in production?: yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
**Issue reported by: @hannojg **
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1688580518417739