Sample questions
React Context StateDifficulty 1
Two sibling components, SearchBox and ResultsList, both need the same query string — SearchBox writes it, ResultsList reads it. Right now each has its own local useState, so they drift out of sync. What is the idiomatic React fix?
- aMove
query state up to the shared parent and pass it plus an updater down as props to both children✓ - bGive
ResultsList a useEffect that polls SearchBox's DOM node to read its current input value - cStore
query in a global mutable variable that ResultsList reads on every render - dWrap each sibling in its own separate
Context.Provider so they broadcast state directly to each other
Explanation:Siblings can't share state by talking to each other directly — React data flows down through props, not sideways. The standard fix is 'lifting state up': move the state to the nearest common ancestor, then pass the value and a setter down to both children as props. That guarantees a single source of truth. Reaching for Context here is overkill for two siblings one level apart; Context earns its keep once a value needs to cross many levels or many unrelated branches, not for a simple parent-of-two case.
React Context StateDifficulty 2
In React's data flow, a child component needs to tell its parent that something happened (e.g. a button was clicked). Which statement correctly describes how this fits the "props down, events up" model?
- aThe child mutates a prop object directly, and the parent re-renders because the object changed
- bParent passes a callback prop down; child calls it, and parent updates its own state in response✓
- cThe child dispatches a native DOM
CustomEvent that the parent's own listener happens to catch - dThe child imports the parent component's module and calls its internal state setter directly
Explanation:Data flows down as props; anything going the other way has to travel through a function the parent handed down, not through the child reaching backward into the parent. The parent defines a callback (e.g. onSearch), passes it down, the child calls it when the event happens, and the parent's own useState update is what actually causes the re-render. Mutating a passed-in prop object (a) breaks React's rules for props, and reaching into another module's internals (d) isn't how components communicate.
React Context StateDifficulty 1
In React, createContext('light') sets 'light' as the context's default value. Precisely when does a component reading this context via useContext actually receive that default 'light' value?
- aWhenever there is at least one Provider for this context mounted anywhere in the app, regardless of what
value it was given - bOnly when a Provider passes
value={null}; a Provider passing value={undefined} still falls back to 'light' - cOnly when there is no enclosing Provider at all; a Provider that passes
value={undefined} still wins and the component reads undefined, not 'light'✓ - dOnly on the component's very first render; later renders keep returning
'light' even once a Provider with a real value mounts above it
Explanation:The default argument to createContext is a fallback used only when useContext finds no enclosing Provider whatsoever — it is not merged with, or used to fill in for, an explicit value. A <ThemeContext.Provider value={undefined}> is still a Provider: it wins over the default, so useContext reads undefined, not 'light'. Verified by rendering three siblings side by side in React 19 — one with no Provider (reads 'light'), one wrapped in a Provider with value={undefined} (reads undefined), and one wrapped in a Provider with value='dark' (reads 'dark') — confirming the default only applies to the first case.
React Context StateDifficulty 2
A tree is App -> Page -> Section (only one level of passthrough), and Section needs a currentUser value that App holds. A teammate insists this already justifies a full Context setup. What's the most reasonable junior-level take?
- aAgreed — any prop passed through even one component is prop drilling and must use Context
- bDisagreed — Context should never be used unless the app also uses Redux
- cAgreed — Context is required whenever a value is read by more than one component anywhere in the tree
- dDisagreed — passing through one intermediate component is cheap; Context adds indirection not worth it yet✓
Explanation:One hop through one intermediate component is a cheap, easy-to-follow case, not the kind of deep or wide chain that Context is meant to solve. Introducing Context here adds a Provider, a consumer hook, and an extra layer of indirection for a problem that a single prop already solves cleanly. Context starts paying off once the chain gets several levels deep or the value needs to reach many unrelated branches at once.
React Context StateDifficulty 1
const ThemeContext = createContext('light')
function Toolbar() {
return <Button />
}
function Button() {
const theme = useContext(ThemeContext)
return <button className={theme}>Save</button>
}
function App() {
return (
<ThemeContext.Provider value="dark">
<Toolbar />
</ThemeContext.Provider>
)
}
What
className does the rendered
<button> end up with?
- a"dark" —
Button reads from the nearest Provider above it, regardless of Toolbar in between✓ - b
"light" — Button always gets createContext's default value since Toolbar didn't forward it as a prop - c
undefined — useContext only works when the calling component is a direct child of the Provider - d
"dark", but only starting from the second render
Explanation:Context is not passed through props at all — any descendant, no matter how deeply nested, can call useContext and get the value from the nearest enclosing Provider. Toolbar in between never needs to know the context exists. So Button reads "dark" on the very first render, correctly, without Toolbar forwarding anything.
React Context StateDifficulty 2
const ThemeContext = createContext('light')
function Label() {
const theme = useContext(ThemeContext)
return <span>{theme}</span>
}
function App() {
return (
<div>
<ThemeContext.Provider value="dark">
{/* Label is NOT placed here */}
</ThemeContext.Provider>
<Label />
</div>
)
}
What text does
<Label /> render?
- a
"dark" — a Provider for ThemeContext exists somewhere in the App tree - b"light" —
Label isn't a descendant of that Provider, so it falls back to the default value✓ - cAn error is thrown at render time because
Label isn't wrapped by any Provider - dAn empty string, since context values only resolve inside effects, not during render
Explanation:A Provider only affects components rendered inside it. Here Label is a sibling of the ThemeContext.Provider, not a child of it, so from Label's point of view there is no enclosing Provider at all — useContext returns the default value passed to createContext('light'). This is the classic silent-bug shape: the Provider exists in the file, but the wiring puts the consumer outside its subtree, and nothing errors — it just quietly falls back to the default.