Usage with react-native-navigation about react-native-offline

[smaris]

Got it working by moving the screen options to the wrapping component:

const LoginComponent = withNetworkConnectivity()(Login)
LoginComponent.navigatorStyle = { tabBarHidden: true, navBarHidden: true }

Navigation.registerComponent('Login', () => connect(mapStateToProps, mapDispatchToProps)(LoginComponent), store, Provider)

But I should still have a root component, because now i'm setting listeners on all screens. State will be updated on connection change, so it will try to set state on screens that are unmounted. Any idea how to accomplish this with react-native-navigation?

[rgommezz]

Hi, thanks for submitting your issue.

I am actively working on a branch to release a new version of the library this week.

First of all, if you wanna integrate the library with redux you need to pass false to withNetworkConnectivity, so it should be:

export const registerScreens = () => {
  Navigation.registerComponent('Login', () => connect(mapStateToProps, mapDispatchToProps)(withNetworkConnectivity(false)(Login)), store, Provider)
  Navigation.registerComponent('Home', () => connect(mapStateToProps, mapDispatchToProps)(withNetworkConnectivity(false)(Home)), store, Provider)
}

That way, the state is kept in the store and not passed down as a prop to your wrapped component.

In terms of statics hoisting, that will be fixed with the upcoming release, so you won't have to move the screen options to the wrapping component.

I haven't used react-native-navigation in any project so far, but based on the API it seems to me (at least for Android where I have some knowledge) every time you use Navigation.registerComponent, the library is creating a new Android activity underneath the hood, so you will have different root components depending on your active screen.

That being said, you don't have to worry about listeners. There will be only one active at a time.

I don't know the implementation details on iOS but I guess they should follow a similar approach where the React context is scoped to the active screen.

Apart from statics hoisting, the new version will include Flow support and the possibility of cancelling enqueued actions with another redux action, like NAVIGATE_TO_ANOTHER_SCREEN from navigation-alike libraries, where it may makes sense to discard the fetching action since it won't be relevant any longer, so stay tuned!

Also, if you have suggestions about new features for the library, feel free to open another issue with your ideas :)

[felipemartim]

@rauliyohmc By wrapping up every screen, you end up doing HEAD requests on each navigation transition. Maybe the connectivity change logic could be managed by an event channel in redux-saga, so it could work without having a root component.