Components, Props, and State (Interview Essentials)
Core building blocks: props vs state, one-way data flow, and when to lift state up.
Frontend Interview Team
February 08, 2026
30‑second interview answer
A component is a reusable unit of UI. Props are inputs passed from parent to child (read-only). State is a component’s internal memory that can change over time and trigger re-renders. React apps follow one-way data flow: data goes down via props; user actions go up via callbacks.
Components: what they really are
In modern React, a component is usually just a function:
function Greeting({ name }) {
return <h1>Hello {name}</h1>;
}React calls the function during the render phase to compute UI.
Component boundaries matter
Component boundaries are how you:
- separate concerns
- improve reuse
- reduce re-render impact (smaller subtrees)
Props
What props are
Props are:
- inputs to a component
- immutable from the component’s perspective
- how parents configure children
function Button({ variant, onClick, children }) {
return (
<button className={`btn btn-${variant}`} onClick={onClick}>
{children}
</button>
);
}Interview trap: “Can a child change props?”
Directly, no. A child can request changes by calling a callback provided via props:
function Parent() {
const [value, setValue] = React.useState('');
return <Child value={value} onChange={setValue} />;
}State
What state is
State is the component’s internal memory:
- it can change
- it triggers re-renders
- it should represent UI state (not derived duplicates)
const [open, setOpen] = React.useState(false);Don’t store derived state unnecessarily
Bad:
const [fullName, setFullName] = useState(first + ' ' + last);Better:
const fullName = first + ' ' + last;Store the source of truth; derive the rest.
One-way data flow (how React stays predictable)
- Data flows down: parent → child via props.
- Events flow up: child → parent via callbacks.
This keeps state changes centralized and debugging easier.
Lifting state up (when and why)
When to lift state
Lift state up when:
- two or more sibling components need the same data
- you need a single source of truth
Example:
function Parent() {
const [query, setQuery] = React.useState('');
return (
<>
<SearchBox query={query} onQueryChange={setQuery} />
<Results query={query} />
</>
);
}When NOT to lift state
Don’t lift state if:
- the state is truly local UI state (e.g., “is dropdown open?”)
- lifting makes the tree harder to reason about
Controlled vs uncontrolled (quick note)
Interviewers often connect props/state to forms:
- Controlled input: value comes from state
- Uncontrolled input: DOM holds value; you read via refs
Controlled is more predictable and testable.
Common mistakes / interview traps
- Mutating state directly
state.items.push(x) // ❌Instead create new arrays/objects.
-
Passing new objects/functions every render This can break memoization.
-
Using state when refs are enough If it doesn’t affect render, consider
useRef.
Mini Q&A (practice)
Q1: What’s the difference between props and state?
- Props are inputs from parents; state is internal and mutable via setters.
Q2: Why one-way data flow?
- Predictability and easier debugging.
Q3: When to lift state up?
- When multiple components need to stay in sync.
Summary checklist
- I can define component/props/state clearly.
- I can explain one-way data flow.
- I know when to lift state up.
- I avoid derived state pitfalls.