Allow infinite dependent keys when using withOnyx#385
Conversation
| const key = Str.result(mapping.key, this.props); | ||
| const connectionID = this.activeConnectionIDs[key]; | ||
| Onyx.disconnect(connectionID, key); | ||
| const key = Str.result(mapping.key, {...this.props, ...getOnyxDataFromState(this.state, mapOnyxToState)}); |
There was a problem hiding this comment.
This is one change that is different than the original PR. I realized that the unmount() was still trying to use the old method for getting the key name. This would probably lead to somewhat of a memory leak because it could cause Onyx to keep a bunch of connections that are never disconnected from when components unmount.
There was a problem hiding this comment.
Does removing this change introduce the same problem as previously?
There was a problem hiding this comment.
I can give it a try. That's a good hunch
There was a problem hiding this comment.
No, it doesn't appear to. I think the changes for batched updates was probably the biggest help for preventing the performance problem we saw last time.
There was a problem hiding this comment.
Hm... That's making me nervous.
There was a problem hiding this comment.
I just feel like this might cause more issues down the road.
Are you referring to the change in onUnmount() specifically, or this PR in general?
There was a problem hiding this comment.
This PR in general.
There was a problem hiding this comment.
To dig into this further, I tried the following things:
- Reverted Onyx to the commit where the original PR was reverted. Then I copied these
withOnyxchanges to the code and tried it out. Result: I was not able to duplicate the original performance problem. - Reverted Onyx to the commit of the original PR being merged, and tried it out in the app. Result: I experienced the following fatal error (caused by the
initialValuechange). After fixing only that fatal error I was still not able to reproduce the original performance problem, though I did see that the report switching was taking about 2-3x longer.
I'm not sure if this fatal error was what we experienced when the original PR was deployed. We definitely witnessed the app hanging and no one could report any JS console errors or record performance profiles, but that was about it.
Conclusion: I am feeling pretty good about the changes in this PR in general. The worst that can happen is we have to do another quick revert, which would stink, but it's also not the end of the world.
There was a problem hiding this comment.
One thing I did not try was using the original commit from Onyx and a commit from App on the same day... I can do that if you would like.
There was a problem hiding this comment.
Sounds good to me. I'll continue my testing.
| if (statePropertyName !== 'initialValue' && mapOnyxToState[statePropertyName]) { | ||
| // eslint-disable-next-line no-param-reassign | ||
| mapOnyxToState[statePropertyName].previousKey = key; | ||
| } |
There was a problem hiding this comment.
This is another small change from the previous PR. When initialValue was integrated, it lead to a situation where mapOnyxToState.initialValue: false, which caused mapOnyxToState[statePropertyName].previousKey to throw an error (because you cannot set .previousKey on the value false).
|
Thanks @tgolen. I'll finish my review today as well! |
Reviewer Checklist
Screenshots/VideosWebScreen.Recording.2023-10-10.at.2.54.57.AM.movMobile Web - ChromeScreen.Recording.2023-10-10.at.3.00.10.AM.movMobile Web - SafariScreen.Recording.2023-10-10.at.2.59.26.AM.movDesktopScreen.Recording.2023-10-10.at.2.57.27.AM.moviOSScreen.Recording.2023-10-10.at.2.58.26.AM.movAndroidScreen.Recording.2023-10-10.at.3.00.48.AM.mov |
|
@tgolen Have a look at the total JS heap size. With the updated code, its going over 700MB. Without this PR After this PR |
|
@allroundexperts I have done some memory testing and tried to be very methodical about it so that it is properly comparing apples to apples. My testing procedure is:
You can see a video of it here2023-10-06_08-20-47.mp4I repeated this test two times, in three different code configurations (for a total of 6 results), to get a nice sampling. The code configurations I used were:
ResultsConclusionThere is no significant memory usage increase with this change. |
|
Bump @allroundexperts and @MonilBhavsar for reviews please. This has been lingering for a while with no requested changes. |
|
On it today @tgolen! |
MonilBhavsar
left a comment
There was a problem hiding this comment.
Sorry, was waiting for C+ review. Looks good to me overall!




This is a redo of #355 which had to be reverted due to performance issues.
Details
There were virtually no differences between this change and the previous change. This is what I did to try and ensure it doesn't leed to another performance issue:
Related Issues
Related to Expensify/App#28824
Automated Tests
Covered by unit tests
Linked PRs
Expensify/App#28866