kirillzyusko / react-native-bundle-splitter

HOC for lazy components loading

Home Page:https://kirillzyusko.github.io/react-native-bundle-splitter/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Does this library work with react-native 0.62 and react-navigation 5 ?

Eyesonly88 opened this issue · comments

commented

TLDR; YES.

Hi @Eyesonly88

Yes, it works with react-navigation 5.
In case of usage this library basic principles are the same, you should wrap your screen with register in HOC and pass then wrapped component as screen:

<Stack.Screen
        name='Home'
        component={register({ require: () => require('./home') })}
        options={{
            // your screen options
        }}
/>

Or with wrapping on index file level:

// home/index.ts
import { register } from 'react-native-bundle-splitter';

export default register({ 
    require: () => require('./View')
});

// routes.ts
import Home from './home';
...
<Stack.Screen
        name='Home'
        component={Home}
        options={{
            // your screen options
        }}
/>

Regarding RN 0.62 - on this version everything works fine. I haven't tested yet, because on my project we are going to migrate on 0.63.x skipping 0.62 (given the fact, that release 0.63 will be very soon). However, I know a lot of developers who uses this library on 0.62 and everything works fine there.

Please, let me know, whether I answered on your question or not. In this case I can close this issue and be sure, that I helped you. Thanks! 😎

commented

Awesome, thank you for the quick response. I'll give this a go and report the results here.

commented

Ok so it works with RN 62.2 and react navigation 5.5.0. However, I’m getting some weird results and I’m not sure if my benchmarking is correct or if the RN upgrade from 59 to 62 made the app slower or what.

Here’s the gist of it:

My production app on play store uses RN 59.0 and first signup screen loads in 2-3 seconds.

After upgrading to RN 62 without applying this library, average load for signup screen is 6-7 seconds!!!

After applying this library, average load is 4-5 seconds.

There is clearly an improvement but overall, somehow my production app using RN59 is twice as fast as my app with RN 62 + this library.

Something is clearly off but no idea what.

I tested on the same Android device Samsung S6 with a release version of the app and I closed the app completely and reopened between tests. I did 10 tests for each scenario!

Any ideas lol?

Hm, it's really interesting. I have some ideas on which you could look at.

But first of all, if you want to continue discuss this topic I would suggest you to close this issue (since we clarified, this library works in combination with RN 0.62 and react-navigation 5😄 ) and open new issue with your problem (performance degradation after migration to the new RN version). In this case other people, who have similar issue can easily find their problem in issues.

According to your problem. The fact that your start time has increased dramatically (from 2-3 seconds to 6-7) is unacceptable.

Firstly, I would like to offer you to understand the reason for such a fall. What really increased the launch time: loading the JS bundle, initializing native modules, and so on. Since you use 0.62, there is support for flipper. You can try using this plugin (although it only works for iOS. By the way, how your app works on iOS - has the launch time increased there?)

Secondly, I would compare the size of the .apk files before and after the migration. I have a suspicion that, perhaps, flipper for some reason began to assemble in the production builds.

Third - which engine do you use? Starting from 0.59, with each release for android, RN delivers the newest JSC. I would recommend to check that there was no degradation of the JSC version. As an addition to this point, I can recommend to use the Hermes engine. It also helps to significantly reduce startup time.

commented

Yes good point, i'll close this issue and make a new one. Thank you for the tips.
Funny enough, during the upgrade, I actually removed a lot of unused code, dependencies and assets. So I was expecting the app to go down in loading startup to like 1 second or so (that was my hope). Anyway, I'll create a separate ticket with more details.