React Native with Context API warnings: "Require cycles are allowed, but can result in uninitialized values... "

Question

When I use React's Context API in my Expo React Native project get this warning:

Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.

Im creating a context in App.tsx:

import Start from "./start";

export const AppContext = React.createContext({
  isLandscape: true,
});

export default function App() {
  return (
    <AppContext.Provider value={{ isLandscape: false }}>
      <Start />
    </AppContext.Provider>
  );
}

And in a Start.tsx component I'm using the context:

import { AppContext } from "./App"

export default function App() {
  const context = React.useContext(AppContext);
  console.log(context);

  return (
    <Text>Sutff</Text>
  );
}

I looks like the warning is because App imports Choose which then imports the context from App again. Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle

However isn't this how the Context API is supposed to be used? How do people normally deal with this when using the Context API in React Native?

Harlin

Answer 1

To break a cycle, move the shared context to a separate file.

// in AppContext.js

export const AppContext = React.createContext({
  isLandscape: true,
});

and then in App.js and Start.js, import context from that file.

import { AppContext } from './AppContext'

Thus, instead of having App <-> Start depend on each other, you now have App -> AppContext and Start -> AppContext, thus breaking the cycle.

Kisung

Why does this happen? – Vitalize

@Vitalize If I wait for you and you wait for me, we never go. If instead we both wait for someone else, then as soon as that person goes, we go with them. Now JS actually doesn't get into a deadlock but tries to still load cyclic dependencies (sort of like when I decide to go and hope that you go, too), and some of the time it's fine (for example in the OP example, it can first initialize AppContext in App.tsx, then App in Start.tsx, and finally App in App.tsx) but if you had A = B in one file and B = A in another file, one of them would be executed first when the value is still undefined. – Kisung

I don’t think I follow you at all. I don’t think it should be about what files things live in, it should be about when functions get called in a particular order – Vitalize

I think you're confusing two things. In Node/JavaScript/TypeScript, files (modules) are loaded and executed line by line, as the program encounters them. That means that all import, export, and top-level assignment statements get executed immediately (when that file is loaded, i.e. referenced by some other file). If the program encounters a function statement, instead of executing that function (its body) immediately, it defines it. Later on, functions can be called by appending parenthesis, like myfn(). In the case of React components, the React "framework" calls those functions for you. – Kisung

Yea so calling a function wouldn’t call all the functions that lives in the same file – Vitalize

Calling a function just executes that function, nothing else. However, when the application starts, it needs to load all of the files (that are imported or required), and it executes all the top-level code within them. That means the more files (including 3rd party modules) you have, the longer it takes for your app to start. (You may optimize this with dynamic imports reactnative.dev/docs/ram-bundles-inline-requires which only load a module once it's actually used.) – Kisung

It's been a while but what do you exactly mean by moving the shared context to a separate file? – Reformer

@Reformer If you have code that is defined in one file but doesn't depend on anything else in that file, and other files also import that code, then it's a sign that such code should be move into its own file. – Kisung

hello I am using typescript so where can i put this code and how it's work please explain Thank You – Hidie