-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Perf: remove Onyx usage from withLocalize
#4253
Conversation
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.
Nice improvement!!
When we update the locale, Will the app re render components. I don't think it will. |
src/libs/translate.js
Outdated
|
||
function getPreferredLocale() { |
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.
NAB: For consistency, we're missing a function doc here -- even though its function is obvious.
Nice optimization!
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.
- If it has a return value it needs a doc but not necessarily a description.
That's a good point. I wouldn't have thought so either. |
Ohhh... hmmm yeah, that kind of sucks. |
When does that happen, isn't the app reloading when a new locale is selected? |
You can test this by changing the language in the preferences (maybe you need to force being in the bet if that's not done by default in dev). And no, it does not reload, all components that are using withLocalize will re-render themselves. |
I've mentioned this at Slack, there's another way to implement the HOC and it will not suffer this problem: https://expensify.slack.com/archives/C01GTK53T8Q/p1627403864349200?thread_ts=1627393814.334100&cid=C01GTK53T8Q The changes would be slightly more, but it might be an even faster if the HOC is implemented through I'll try it out tomorrow and do another benchmark |
Looks good so far and definitely up for more improvements. I'm adding a link back to the original issue in the description so there is some more context. |
But I think maybe this needs a new issue? |
Yeah, I'll probably have to spent some more time here, and then test/bench the changes on the remaining platforms. I can open an issue tomorrow |
👍 Sounds great! |
@marcaaron I've created a new issue: #4268 and updated the PR description with the link |
6bf4ff2
to
72800fc
Compare
Updated implementation and posted new benchmarks here: #4268 (comment) I think another possible optimization that might be applied at the moment is to class LocaleContextProvider componentDidMount() {
this.connectionId = Onyx.connect({
key: ONYXKEYS.NVP_PREFERRED_LOCALE,
callback: (val) => {
if (val) {
this.setState({preferredLocale: val});
}
},
});
}
componentWillUnmount() {
Onyx.disconnect(this.connectionId);
} This skips creating the |
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.
These changes look good to me and do make chat switching significantly faster. I can't really think of any reasons why we should not do this (other than people being unfamiliar with the Context API). Probably as a follow up we can add something to the documentation about how to approach using withOnyx
when a component will be used a great number of times throughout the app or some list.
const WithLocalize = forwardRef((props, ref) => ( | ||
<LocaleContext.Consumer> | ||
{/* eslint-disable-next-line react/jsx-props-no-spreading */} | ||
{ translateUtils => <WrappedComponent {...translateUtils} {...props} ref={ref} />} |
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.
NAB, Unnecessary space here.
Yeah, I think there are probably better optimizations to focus on. This is already so great 🎉 |
🚀 Deployed to staging in version: 1.0.81-7🚀
|
@kidroca Hello! Any QA tests needed for this PR? |
@isagoico No specific test steps other than basic regressions as translations are used everywhere. |
@kidroca this PR created this regression. |
The referenced comment was made for the logic in the initial PR, since then the code changed quite a lot We can fix this by passing I see a new ticket have been opened: #4359 IMO, since it was tracked it to this PR, it would be easier and faster to address here by re-open the existing issue |
IMO yes, because it's a feature that worked and was broken by this PR. |
@kidroca Please close that Issue when you submit a fix via the PR. That issue was created for tracking the problem. |
Shouldn't I be assigned to the new ticket as well then? |
Is that any advantage of assigning an issue? Asking in general. |
It makes it easier to find things if they are assigned to the people that worked on them. It is also used in some of our internal tooling to for example assign reviewers for issues or PRs. |
Oh, hmm, we merged it because the implementation was entirely different. In short, we didn't suspect the new one would have the same issue. |
🚀 Deployed to production in version: 1.0.82-7🚀
|
@marcaaron
Details
This component is one of the most used components and has more than 310 instances depending on chat size
Instead of creating a new connection for each
withLocalize
usage - use the already cached value intranslate
This significantly reduces the
Onyx.get
load that is caused by all the connectionsFixed Issues (Related To)
Fixes #4268
Tests
I'm using
Onyx.printMetrics()
to monitor theOnyx.get
calls that happen during init: https://github.com/Expensify/react-native-onyx#benchmarksMy Benchmarks
Before
preferredLocale
After
QA Steps
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android