-
-
Notifications
You must be signed in to change notification settings - Fork 5k
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
react-navigation 5.0 is extremely slow. #7756
Comments
Hey! Thanks for opening the issue. Can you provide a minimal repro which demonstrates the issue? Posting a snippet of your code in the issue is useful, but it's not usually straightforward to run. A repro will help us debug the issue faster. Please try to keep the repro as small as possible. The easiest way to provide a repro is on snack.expo.io. If it's not possible to repro it on snack.expo.io, then you can also provide the repro in a GitHub repository. |
Hey! Thanks for opening the issue. Can you provide more information about the issue? Please fill the issue template when opening the issue without deleting any section. We need all the information we can to be able to help. Make sure to at least provide - Current behaviour, Expected behaviour, A way to reproduce the issue with minimal code (link to snack.expo.io) or a repo on GitHub, and the information about your environment (such as the platform of the device, exact versions of all the packages mentioned in the template etc.). |
i have this problem too in debugger mode, i used TabbarBottom with icons and drawer, but when i click icons to load routes in debugger mode is slow and sometimes does not reaction to click |
Same here, Transitions are laggy even running heavy functions in InteractionManager.runAfterInteractions(...). Btw, v4 is bit faster than v5 with same codebase |
Same here, with v5 it is difficult to work in debugger mode, as tab buttons not reacting on press, or reacting after long time. Without debugger turned on, everything works smooth |
I've recently migrated from v3 to v5 using |
@andreipfeiffer in android and debugger mode this problem happening, I didn't test in IOS |
|
@Neha0595 why you closed this issue? |
@medelvann By mistake I tap on close button |
Are you using a nested tab navigator? I have a noticeable delay with a nested tab navigator inside another one. The parent tab navigator navigates instantly, but the nested one takes at least half a second to navigate from one tab to another. There is something odd with the nested navigation because when I swipe between the nested tabs, it is instant, there is no delay, so the view is already rendered. I also noticed that if I move all the screens to the parent it is still instant navigation. |
Thanks @yenda, I've had the same issue with a BottomTabNavigator nested inside a StackNavigator. It also fixed weird delays / bugs on my UI:
Would it be possible that this use case of nested navigation, somehow triggers re-render of other components, causing the app to slowdown and having other side effects? (again, my app is plain UI, nothing fancy, no backend plugged yet) On a side note, on Android devices, I still have weird issues with transition effects (tab and stack transitions)... Might be something else though. |
looks like you might be creating components during render.
debugger always has issues with touchables and timing related stuff, nothing new in v5. your code is running on chrome browser instead of the device, so it's going to run differently |
@kamui545 btw I solved my nested navigator issue, I noticed the screens were all re-rendering on tabPress, the issue for me was that the navigation-props were passed as input that triggered re-render. I am not sure it applies to you because I'm writing in clojurescript but basically all I need to fix that was passing the navigation props only on component creation and not as input of the rendering function, so that changes to the navigation props don't trigger a re-render. I also had another bug with a custom bottom bar, where I was accidentally emiting the tabPress event outside of the tabPress function, as a consequence my nested tab navigator was re-directing to the first screen of the nested tab-navigator when I was trying to do an action that would trigger a re-render of the bottom bar |
I've tested and this problem only happens on android on debugger mode. On ios, it's working smoothly with debugger mode on. |
If you are using a I should note that for me, this has nothing to do with the debugger - I have it disabled and notice a significant slowdown. Had v3 and v5 running side by side in simulators and could see the difference. |
@scarlac Thanks for this answer. |
I don't have an example that I can share. I did not find a workable solution - hence why I said WIP (Work In Progress). If you wrap the function that outputs all your <Stack.Screen/> stuff, you see an improvement in performance but you'll also break your app. It is a regression bug. |
Any updates on this? We are still experiencing this unacceptably slow switching. |
1 similar comment
Any updates on this? We are still experiencing this unacceptably slow switching. |
@richagain Your best hope is to open a new ticket and compile as much proof as possible. If possible, provide a test case that demoes the issue so maintainers can fix it. |
after upgrading the version of react navigation, the issue was fixed. |
from version... to version ?? Please provide more details to make your comment helpfull. |
@richagain still the same thing ); |
Any update on this? I am also facing the same issue on Android. |
I think the issue is related to the number of nested tabs. Experiment by reducing the number of tabs you have. We were able to work around the issue by removing a tab. Different designs will not always allow for that. @satya164 this is not because of the debugger, although connecting a debugger will certainly slow performance in any app. We had this issue in an app released on Firebase on a test device. No debugger was connected. My company has moved to other cross-platform frameworks for mobile. Where performance is critical, we write native code. Heavy dependence on third-party libraries has its pros and cons. |
@dane-du-plessis The number of nested tabs does indeed make a difference. We were able to get the performance to an acceptable (but still not perfect) level by decreasing our tabs from 5 to 3. |
the problem comes in when you switch between nested tabs this is major issue and should be solved uptill now |
android not press bottm tab navigation when debug . can i h y? const tabIconHome = require('./src/assets/images/BottomTab/tabIconHome.png'); const Stack = createStackNavigator(); function HomesStack() { function HealthRecordsStack() { function AccountsStack() { function BottomTabNavigation() { function AuthsStack() { const store = createStore(reducer) const App = () => {
); const styles = StyleSheet.create({ export default App; |
I have the same problem, switching back to v3 fixes the issue for me, but this is obviously not ideal. I even tried v6, also too slow. Especially the bottom tabs are an issue. Edit: I also tried v4, same slowness issue. |
Any updates on this issue ? I am still facing this problem and tried all solutions above, they didn't help. Switching back to v3 is so painful for me :(. |
Hi NguyenDuyThang. Bạn nên dùng trinh debug mới nhé thì sẽ giải quyết vấn đề trên flipper. k dubug với chomre nữa |
Hello i have same problem, and i tried many solutions but its still loading so slow when i do push on navigator |
It can't render even 10 simple components without delays.. |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
1 similar comment
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
I have figured out the problem. It turned out the redux is the problem. In my case, when I use the connect method of redux in class component style, it somehow takes time to connect the component to redux store before we navigate. The bigger your redux is, the more time it takes. I solve it by applying hooks (functional component) instead of class component so that I no longer use the connect method anymore. |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
I have two nested navigators in my bottomtabs navigator and it completely killed the app performance. |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
I have a simple project here: https://github.com/dotku/dk-i18n-trading-calculator feel that switching between screen, the transition is still slow; might take 1 sec to switch between different screen. Any performance tune up hint? or performance tracking tool to help the issue? |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
Strange that nobody seems to care about this issue. This inevitably pops up if you really try to make use of React how it is supposed to be used. Deep nesting and careful design of the mutual relationships and props passing. After spending dozens of hours on this particular bug, I came up with a solution that fixed 99% of our performance issues. I think that the solution in general should be implemented upstream (i. e. in this plugin) and that it is not something to bother the downstream developers with. So basically we had a lot of these, nested
Instead, what you should do according to the official solution is concatenating all children into an extra component
and then
However, that way you can't pass any custom props. So instead, what you really should do is
and then outside (!) of any (functional, class) component, at the top of the
Going with this pattern over the entire app frontend resulted in a HUGE speedup. |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
@aximut No one can help you if you do things in the wrong way and do not provide a quick runnable repro (You can see someone gave the repro recently).
https://github.com/react-navigation/react-navigation/blob/main/example/src/index.tsx#L322-L329 |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
@aximut the performance concerns about what you are doing are clearly documented. I recommend reading the documentation first to avoid wasting time. https://reactnavigation.org/docs/hello-react-navigation#passing-additional-props |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
Still an issue. Facing slow navigation on Android. |
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
I just update my existing project from react-navigation 3.0 to 5.0, I experienced a very slow transition from one screen to another, revert back to 3.0 again the transition is much fast as compared to 5.0
The text was updated successfully, but these errors were encountered: