[React](/courses/reactjs) Context is appropriate when you need to share data across many components without manually passing that data through every intermediate component using props. It works best for **broadly shared and relatively stable data**, such as: * Application theme * Language or locale * Authenticated user information * User preferences * Feature flags * Configuration values For example, imagine your application has a logged-in user's information that is needed by the navbar, profile page, dashboard, and settings page. Without Context, you may have to pass the user through several components: ```jsx ``` This is known as **prop drilling** because the same value is passed through components that may not even need it. [React](/courses/reactjs) Context allows components to access the shared value directly. --- ## Basic Context Example First, create a context: ```jsx import { createContext } from "react"; export const UserContext = createContext(null); ``` Then provide the value at a higher level: ```jsx import { UserContext } from "./UserContext"; import Dashboard from "./Dashboard"; export default function App() { const user = { name: "Asif", role: "Developer" }; return ( ); } ``` Now any component inside the provider can access the user without receiving it through props. ```jsx import { useContext } from "react"; import { UserContext } from "./UserContext"; export default function Navbar() { const user = useContext(UserContext); return (

Welcome, {user.name}

); } ``` The component tree can now look like this: ```text App │ ├── Navbar ├── Dashboard │ ├── Profile │ └── Settings ``` All of these components can read the same context value directly. --- ## What is the performance concern with Context? The main performance concern is that **when a Context Provider's value changes, React re-renders the components consuming that context**. Consider this example: ```jsx import { createContext, useContext, useState } from "react"; const AppContext = createContext(); function App() { const [user, setUser] = useState({ name: "Asif" }); const [count, setCount] = useState(0); return ( ); } ``` Now suppose `Navbar` only needs the user: ```jsx function Navbar() { const { user } = useContext(AppContext); console.log("Navbar rendered"); return

{user.name}

; } ``` And `Counter` only needs the count: ```jsx function Counter() { const { count } = useContext(AppContext); console.log("Counter rendered"); return

Count: {count}

; } ``` When this runs: ```jsx setCount(count + 1); ``` the provider value changes: ```jsx { user, count } ``` Because the Context value changed, components consuming `AppContext` may re-render. That means: ```text count changes ↓ AppContext value changes ↓ Context consumers are notified ↓ Navbar re-renders Counter re-renders ``` Even though `Navbar` does not actually use `count`, it consumes the same context. This is one of the major reasons why putting too much state inside a single Context can create unnecessary rendering work. --- ## Why large Context objects can become a problem A common mistake is creating one global context containing almost everything: ```jsx {children} ``` Now imagine: ```text searchQuery changes on every keystroke ``` or: ```text messages change several times per second ``` The Context value keeps changing. Components consuming that context can therefore be updated much more frequently than necessary. This can become noticeable in a large application. --- ## Better approach: Split Contexts Instead of creating one huge context: ```jsx const AppContext = createContext(); ``` create smaller contexts based on responsibility: ```jsx const UserContext = createContext(); const ThemeContext = createContext(); const NotificationContext = createContext(); ``` Then provide them separately: ```jsx ``` Now a component interested only in the theme can consume: ```jsx const theme = useContext(ThemeContext); ``` If the user changes but the theme does not, the theme consumer does not need to react to the user context change. Conceptually: ```text UserContext ├── Navbar └── Profile ThemeContext ├── Header └── ThemeButton NotificationContext └── NotificationPanel ``` This keeps unrelated state separate. --- ## Another performance issue: Object identity Consider this provider: ```jsx {children} ``` Every time the provider component renders, this creates a new object: ```jsx { user, logout } ``` Even if `user` has not changed, the object itself has a different reference. Conceptually: ```js {} === {} ``` returns: ```js false ``` Because they are two different objects. For some Context designs, you can stabilize the provider value with `useMemo`: ```jsx import { useMemo } from "react"; const value = useMemo(() => { return { user, logout }; }, [user, logout]); return ( {children} ); ``` Now the object is recreated only when one of its dependencies changes. However, `useMemo` should not be added blindly. The more important architectural improvement is often to **keep Context focused and avoid storing unrelated, frequently changing state together**. --- ## When should you avoid Context? Context is usually not the best choice for highly dynamic state such as: ```text Mouse coordinates Real-time messages Rapidly changing search state Large frequently updated data collections Complex application state with many independent consumers ``` For example: ```jsx const [mousePosition, setMousePosition] = useState({ x: 0, y: 0 }); ``` If this value updates dozens of times per second and many components consume the context, it can result in excessive re-rendering. For complex global state, a state-management solution that supports more granular subscriptions or selectors can sometimes be more appropriate. --- ## Good Context Use Case Theme is a classic example because it is: * Needed by many components * Usually changed infrequently * Simple to represent ```jsx import { createContext, useContext, useState } from "react"; const ThemeContext = createContext(); function App() { const [theme, setTheme] = useState("light"); return ( ); } function Navbar() { const theme = useContext(ThemeContext); return ( ); } ``` Context works well here because the theme is shared throughout the application but normally does not change continuously. --- ## Context vs Props Use props when the data only needs to travel through a small part of the component tree: ```text Parent ↓ Child ``` Example: ```jsx ``` Use Context when the same data is required by many deeply nested or widely separated components: ```text App │ ├── Navbar │ ├── Dashboard │ ├── Sidebar │ └── Profile │ └── Settings ``` If all these components need the authenticated user, Context may be appropriate. --- ## Interview-Ready Answer React Context is appropriate for data that needs to be shared across many components and is relatively stable, such as theme, locale, authenticated user information, feature flags, or application configuration. It helps avoid prop drilling by allowing deeply nested components to access shared values directly. The main performance concern is that when the Provider's value changes, components consuming that Context are notified and can re-render. Therefore, putting large amounts of unrelated or frequently changing state into a single Context can cause unnecessary renders. To reduce this problem, I usually keep contexts small and responsibility-specific, split frequently changing values into separate contexts, stabilize provider values where appropriate, and use a state-management solution with selector-based subscriptions when the application requires highly granular or frequently updated global state. ### One-line interview answer > Use Context for broadly shared, relatively stable data such as authentication, theme, or locale. The key performance concern is that changing the provider value can re-render its consumers, so avoid large frequently changing contexts and split state or use selector-based state management when finer-grained subscriptions are required.