-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does removing this change introduce the same problem as previously?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can give it a try. That's a good hunch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... That's making me nervous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
withOnyx
changes 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
initialValue
change). 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, was waiting for C+ review. Looks good to me overall!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
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