Better way to use multiple context providers in ReactNative

Question

I am having an app in which I am using 3 Context Provider. For the app to work, I have to wrap <App/> in all these providers. As my app grows I am expecting to have a few more providers for more types of data I have to connect with. I have already started to feel that there may be a better way to pass providers into the <App />.

My App.js Code:

import React from 'react';
import { createStackNavigator } from 'react-navigation-stack';
import { createAppContainer } from 'react-navigation';
import { Provider as BlogProvider} from './src/context/BlogContext';
import { Provider as VehicleProvider} from './src/context/VehicleContext';
import { Provider as AuthProvider} from './src/context/AuthContext';

import IndexScreen from './src/screens/IndexScreen';
import ShowScreen from './src/screens/ShowScreen';
import CreateScreen from './src/screens/CreateScreen';
import EditScreen from './src/screens/EditScreen';
import VehicleScreen from './src/screens/VehicleScreen';

const navigator = createStackNavigator(
  {
    Index: IndexScreen,
    Show: ShowScreen,
    Create: CreateScreen,
    Edit: EditScreen,
    Debug: DebugScreen,
    Vehicle: VehicleScreen,

  },
  {
    initialRouteName: 'Index',
    defaultNavigationOptions: {
      title: 'Main'
    }
  }
);

const App = createAppContainer(navigator);

export default () => {
  return (
    <BlogProvider>
      <VehicleProvider>
        <AuthProvider>
             <App />
        </AuthProvider>
      </VehicleProvider>
    </BlogProvider>
  );
};

Some of the questions I have are:

1. Is there a better way to use multiple context providers in an App.
2. Does the order in which these providers are nested have any impact on the App?
3. Can we skip adding provider in <App/> and instead import them in a any screen where it's required and wrap that screen element in it?

Answer 1

I won't answer in order it's asked.

Answer 3

If a provider ONLY provides context for a specific Component, you should import and use it in that Component. DO NOT wrap App with it.

The reason is when ever provider updated the every consumer will be re-render, you can't no use React.memo or ReactPureComponent or shouldComponentUpdate to stop it. You should not overuse context

const Root =() =>{
  return(
    <AppProvider>
      <ComponenAtProvider>
       <App/>
     <ComponenAtProvider>
    </AppProvider>
  )
}

const App =() =>{
  return(
    <>
      <ComponentA/>
      <ComponentB/>
    <>
  )
}

const  ComponenAContext = createContext()
const ComponenAtProvider = ({children}) =>{
  // If any value here is updated ==> all consumer will be render
 // ==> App re-render ==> ComponentA and ComponentB re-render
  return(
    <ComponenAContext.Provider value={{value1, value2, valu3}}>
      {children}
    </ComponenAContext.Provider>
  )
}

You should do this instead

const Root =() =>{
  <AppProvider>
      <App/>
  </AppProvider>
}

const App =() =>{
  return(
   <>
    <ComponentA/>
    <ComponentB/>
   <>
  )
}

const ComponentA = () =>{
  return(
    <ComponenAtProvider>
      <App/>
    <ComponenAtProvider>
   )
}

const  ComponenAContext = createContext()
const ComponenAtProvider = ({children}) =>{
  // If any value here is updated ==> all consumer (ComponentA only) will be render
  return(
    <ComponenAContext.Provider value={{value1, value2, valu3}}>
      {children}
    </ComponenAContext.Provider>
  )
}

Answer1

The answer 3 can be the answer for this, use context in the right place (For the Components which consume the context only. DO NOT randomly every context at App level). If your context is frequently updated, I recommend to not use other ways so you can use React.memo or PureComponent or shouldComponentUpdate to prevent unwanted re-render to optimise performance.

Answer2

The order doesn't impact on the App

Answer 2

Answers

Answers 1:

1. there is no better way to add app-level provider but some provider do not have context app-level mean (we do not need context in-app everywhere). Some providers have module levels. so you can wrap outside specific tree or component

const UserScreen=()=>(
<UserProvider>
  <UserScreen />
<UserProvider />
)

Answers 2:

2. in working there is no an effect but sometimes we need to call child function from parent, therefore, we need to use ref. in this nested level provider we have to use forwardRef. rest of the things work fine

Answers 3:

3. yes we can skip provider in App.js if that provider is not app-level mean we do not need context every where in app. if we need context in one or two screen or one tree then we can wrap that screen or tree in provider and do not use in app.js

Answer 3

1. I'm not sure what you mean with "better". If you just want to clean up your App component, you can abstract the Provider rendering into a separate function. This or this might help you accomplish it according to your needs

2. If, like your example, you wrap your entire application with all Providers and they are independent of each other, then the order would not matter. Otherwise they behave no different than other components, only children have access to its data and the data flow is unidirectional.

3. Yes, there is no need to provide all data to your entire application.

Answer 4

1. Is there a better way to use multiple context providers in an App.

Answer: Yes

• you can use whatever number Context Providers to wrap around your App, but make sure that data of those Providers should not be frequently updated and they are treated as global state which means they are accessed or will be accessed from anywhere in your app. Ex: your app theme, authentication status, user's profile,...
• If data is considered as specific use-case which is only used in just few places in your App, you should not use Context Provider, because if data is updated, all its chilren are forced to re-render, no matters you use any React APIs to prevent it like React.memo. Refer to this

2. Does the order in which these providers are nested have any impact on the App

Answer: Yes

• As I said in answer 1, if Provider has data that is updated frequently is parent of those which are having less frequently updates, it will impact all its children, so you can refactor by wrapping the most less updated outermost as parent.

3. Can we skip adding provider in and instead import them in a any screen where it's required and wrap that screen element in it?

Answer: it is up to your use case.