Let's think about it this way for a second
The Context API lets any component in the tree access global-ish state (user login info, theme, language) directly, without passing it down through props at every level — you create a Context with createContext(), wrap a value with a Provider, and read it from a consumer component with useContext(). Login state (whether the user is logged in) is information the whole app cares about, which makes it a classic use case for the Context API.
Let's connect this to a real-world scenario
Wrap AuthContext with a Provider at the App root, and no matter how deeply nested a screen is (Home → Detail → Comment → Reply), it can get the user info just by calling useContext(AuthContext), without any prop passing. Using Context for large state (large lists, frequently-changing data) can lead to more unnecessary re-renders — in that case, consider a dedicated state library like Redux or Zustand.
Code Example
import { createContext, useContext, useState } from 'react';
const AuthContext = createContext(null);
export function AuthProvider({ children }) {
const [user, setUser] = useState(null);
return (
<AuthContext.Provider value={{ user, setUser }}>
{children}
</AuthContext.Provider>
);
}
export function useAuth() {
return useContext(AuthContext);
}
// Any nested component:
// const { user } = useAuth();
// return <Text>{user ? `Welcome, ${user.name}` : 'Please log in'}</Text>;No matter how deep the component tree goes, you can get the user info just by calling useAuth(), with no prop passing needed.Try it in 5 minutes
Build a ThemeContext (light/dark mode) yourself and have 2-3 nested components read the theme with useContext.
A quick word of caution
Every time the context value changes, **all** of the Provider's child components re-render (whether they use useContext or not) — in performance-sensitive apps, it's better to keep contexts granular (split into several smaller contexts).