App: [hold for payment 25 august] Onyx changes break Exisiting App architecture.
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
cc: @marcaaron @kidroca
ISSUE
There few parts that will stop working due to the recent changes to Onyx. We have to either plan for migration or fix Onyx so that those continue working.
There is a component Enablepayment which uses the following implementation.
- It disregards the stored values in Onyx for userWallet. https://github.com/Expensify/App/blob/50828ab6752324988fbfdc7020878c80adf174bd/src/pages/EnablePayments/index.js#L50-L58.
- We start with a
userWallet:{}value. - After the component is mounted we make an API call to get the new data.
- But If the data coming from the backend is the same as the stored value in Onyx, there will not be any rerendered.
- Due to this, we will never be able to show the real data on the screen.
- There will be many instances of this approach in the App and multiple times data will not change but we still want to make a request to check for updated value and show it to the user.
Slack thread => https://expensify.slack.com/archives/C01GTK53T8Q/p1628106963153400
Expected Result:
UI should be updated to show the recent state of data.
Actual Result:
- No change in the UI state.
Workaround:
None. It breaks the App.
Platform:
Where is this issue occurring?
- Web
- iOS
- Android
- Desktop App
- Mobile Web
Version Number: 1.0.82 Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation Expensify/Expensify Issue URL:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 58 (54 by maintainers)
Paid with bonus! Thanks @parasharrajat
Any update @MitchExpensify? Sorry for the confusing comment, I have updated it.
Okay thanks for the summary - let’s wait for Marc to get online later and take a look here to give us a forward steer 👍🏽
Cool. Will leave you to use your best judgment here @parasharrajat
Yes, it seems urgent. Both solutions seem like they will solve the deploy blocker and so either is fine by me. We can continue the discussion about deprecating this feature or reducing complexity as an Onyx improvement in a new issue. Sound good?
We agreed that re-rendering the things flagged with
initWithStoredValues: falseshould not be a problem. I don’t think we agreed that we should always callkeysChanged. It makes sense to me that we should not call this if the value has not changed (and a subscriber already possesses the value). The issue is that things which haveinitWithStoredValues: falsedo not have the value but the cache does so they will never be updated. That is my understanding of the situation at least - though I may have missed something.Also, I think if the component is optimized a render should not be big deal. We are already reusing the Onyx subscriptions so resubscribing to WitOnyx should be fast.