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

Hot reload and "You try to add new component with already existing name" error

ku8ar opened this issue · comments

Describe the bug
In dev mode, during application reload, require with name reports the above error.

To Reproduce
Steps to reproduce the behavior:

  1. add require with name
  2. in developer mode, call hot reload of the app

This error cause that we are unable to work in dev mode. Will deleting line of code with this throw have any negative consequences (e.g. memleak in developer mode)?

Hi @ku8ar
Could you add small reproducible demo?
In fact I worked with this library in hot reload mode and didn't encounter any problems.
register function should be called only once. If it's called multiple times, then it may lead to some unexpected problems (such as performance bottlenecks or cache issues). So I would be highly appreciated you if you could create small reproducible demo.

In fact I don't think, that it may lead to some serious issues. However that would be good to understand why it happens. Maybe I should rewrite it to console.warn instead of throwing errors🤔

We have react-navigation v5 in the application and many connections between components. So sometimes it happens that dev mode reloads the entire application (and thus the components with navigation).

Typical code of nav component:

// many imports which editing causes reload of this file

const Wish = register({ name: 'Wish', loader: () => import('src/screens/Wish') })
const Cart = register({ name: 'Cart', loader: () => import('src/screens/Kept') })

export default () => (
 <Tab.Navigator>
   <Tab.Screen name={'Wish'} component={Wish} />
   <Tab.Screen name={'Cart'} component={Cart} />
 </Tab.Navigator>
)

The problem only occurs in developer RN mode (because only then we do reload of files).

So you're saying I can patch this lib so that in dev mode there won't be this bug and the rest of developers won't hate me for it? :D

Anyway, I read where you are from. Good luck in these hard days...

Nice @ku8ar! Thank you for the explanation and the detailed described issue.
I saw, that some people are forking the repo and commenting this line out, but I didn't understand why... Now it's clear.

I will keep this issue opened. I think I will change the approach, and instead of throwing the error I will call console.warn. For developers it will give more flexibility. They will not need to patch the library (they will be able to ignore the warning via LogBox.ignoreLogs). Anyway, I haven't decided how to make it better, so if you have any suggestion - feel free to share it 😊

And I think the reason, why I haven't seen such issues before is because of the fact, that I moved all register function calls into separate index.ts files. And these files never were reloaded, so I didn't see any errors.

It was like:

// src/screens/Wish/index.ts

import { register } from "react-native-bundle-splitter";

export default register({
  name: 'Wish',
  loader: () => import('./View')
});

Inside of src/screens/Wish/View.tsx I had actual implementation of the screen. And inside of navigator I had a reference only to index.ts file, so it was like that:

import Wish from "src/screens/Wish/index";
import Cart from "src/screens/Kept/index";

export default () => (
 <Tab.Navigator>
   <Tab.Screen name={'Wish'} component={Wish} />
   <Tab.Screen name={'Cart'} component={Cart} />
 </Tab.Navigator>
)

So you're saying I can patch this lib so that in dev mode there won't be this bug and the rest of developers won't hate me for it? :D

I think yes. You can just add a link as a comment to the patch, so other developers will be aware of the changes, that you made (and the motivation why you made it).

Anyway, I read where you are from. Good luck in these hard days...

Thanks, mate. I appreciate it!

Thanks for the clarification :) Your coding-style is better. But in the app we're working in, it would require a large code refactor.
Therefore, console.warn will actually be a better idea.

Closed in b0e3ee6