Components, Props, and State (Interview Essentials)

Core building blocks: props vs state, one-way data flow, and when to lift state up.

F

Frontend Interview Team

February 08, 2026

3 min read
Components, Props, and State (Interview Essentials)

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

  1. Mutating state directly
state.items.push(x) // ❌

Instead create new arrays/objects.

  1. Passing new objects/functions every render This can break memoization.

  2. 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.