React Basics Interview Questions and Answers

React is an open source JavaScript library for building user interfaces out of components, where you describe what the UI should look like for a given state and React works out how to update the DOM.

React was created at Facebook and released in 2013. It is a library rather than a full framework: it handles the view layer and leaves routing, data fetching and build tooling to you or to a framework built on top of it, such as Next.js or Remix.

The idea that matters is declarative rendering. You do not write instructions that move the DOM from one state to the next. You write a function of state that returns a description of the UI, and React makes the DOM match that description.

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

Component based architecture, declarative rendering through JSX, a virtual DOM with reconciliation, one way data flow, and the ability to render on the client, the server or to native platforms.

• Components. The UI is built from small, reusable, independently testable pieces that compose into larger pieces.
• Declarative rendering. You describe the UI for a given state; React performs the DOM updates.
• Virtual DOM and reconciliation. React diffs a lightweight tree of elements and applies only the minimum set of real DOM operations.
• One way data flow. Data travels from parent to child through props, which makes it possible to reason about where a value came from.
• Platform independence. The same component model renders to the browser through react-dom, to the server, and to native apps through React Native.

If you are asked to pick the single most important one, pick the component model. Everything else is in service of being able to compose UI out of independent pieces.

JSX is a syntax extension that lets you write markup inside JavaScript. It is not part of the browser: a compiler such as Babel or SWC turns it into ordinary function calls that create React elements.

React uses JSX because rendering logic and markup are genuinely coupled. Splitting them into separate files does not decouple them, it just separates them by file type. JSX keeps a piece of UI and the logic that decides what it shows in one place.

// You write
const element = <h1 className='title'>Hello</h1>;

// The compiler emits (React 17+ automatic runtime)
import { jsx as _jsx } from 'react/jsx-runtime';
const element = _jsx('h1', { className: 'title', children: 'Hello' });

• JSX is optional. You can write React.createElement calls by hand, and the output is identical.
• Attributes use camelCase because they map to DOM properties: className, htmlFor, onClick.
• Expressions go in braces, and only expressions: {count + 1} works, an if statement does not.
• A component must return a single root node, which is what fragments exist for.

The virtual DOM is an in-memory tree of plain JavaScript objects describing the UI. On each render React builds a new tree, compares it with the previous one, and applies only the differences to the real DOM.

A real DOM node is a large object with hundreds of properties, and touching it can trigger layout and paint. A React element is a small object with a type, props and children. Creating thousands of them is cheap.

1. State changes, so React re-renders the component and gets a new element tree.
2. React compares the new tree with the tree from the previous render. This step is called reconciliation.
3. React produces a list of the minimum DOM operations needed and commits them in one pass.

They are unrelated. The virtual DOM is a React implementation detail for computing updates in memory; the shadow DOM is a browser standard for encapsulating a component's DOM and styles from the rest of the page.

The names are similar and nothing else is. This question is asked mostly to see whether you repeat buzzwords or actually know what each thing does.

A component is a function or class that describes UI; an element is the plain object that component returns, describing one instance of what should appear on screen.

// Component: a function
function Button({ label }) {
  return <button>{label}</button>;
}

// Element: a plain object, roughly
const element = <Button label='Save' />;
// { type: Button, props: { label: 'Save' }, key: null, ... }

Elements are immutable. Once created you cannot change an element's props or children. Updating the UI means creating a new element and letting React reconcile it against the old one, which is what makes the diff possible in the first place.

Props are data passed into a component from its parent and are read only inside that component. State is data a component owns and can change, and changing it triggers a re-render.

The practical rule interviewers want to hear: keep state as low in the tree as possible, and if two components need the same value, lift it to their closest common parent and pass it down as props.

Data moves in one direction only, from parent down to child through props. A child communicates back up by calling a function the parent passed it, rather than by writing to the parent's data.

This is why a React bug is usually findable. When a value on screen is wrong, there is exactly one place it can have come from: the component that owns that state. You walk up the tree until you find the owner.

function Parent() {
  const [query, setQuery] = useState('');
  return <SearchBox value={query} onChange={setQuery} />;
}

function SearchBox({ value, onChange }) {
  return <input value={value} onChange={(e) => onChange(e.target.value)} />;
}

Contrast this with two way binding, where the view can write straight back into the model. Two way binding is less code up front and much harder to trace once an app is large.

A key is a stable identifier that tells React which item in a list is which between renders, so it can move, keep or remove the right DOM nodes and component state instead of guessing by position.

Without keys React matches list children by index. If you insert an item at the top of the list, every index shifts, and React thinks every item changed. With stable keys it recognises that one item was added and the rest simply moved.

// Fragile: reorder or insert and state attaches to the wrong row
{todos.map((todo, index) => <Todo key={index} todo={todo} />)}

// Correct
{todos.map((todo) => <Todo key={todo.id} todo={todo} />)}

Keys are also a deliberate tool. Changing the key on a component forces React to unmount the old one and mount a fresh instance, which is the cleanest way to reset internal state, for example when a form should start over for a different record.

A class component extends React.Component, holds state in this.state and uses lifecycle methods. A function component is a plain function that uses hooks for state and effects. Function components are the modern default.

class Counter extends React.Component {
  state = { count: 0 };
  render() {
    return (
      <button onClick={() => this.setState({ count: this.state.count + 1 })}>
        {this.state.count}
      </button>
    );
  }
}

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

• Hooks work only in function components, so all new React APIs target them.
• Function components have no this, which removes a whole class of binding bugs.
• Logic reuse in classes needed higher order components or render props; with hooks it is a custom hook.
• Error boundaries are still the one thing that requires a class, because there is no hook equivalent of componentDidCatch.

A fragment lets a component return several children without adding an extra DOM node. Write it as <>...</> or <React.Fragment>...</React.Fragment>.

A component must return a single root. Wrapping in a div to satisfy that rule pollutes the DOM and, more importantly, breaks layouts where the parent's CSS expects direct children, such as a grid, a flex row, or a table that expects tr elements.

function Row({ cells }) {
  return (
    <>
      <td>{cells.name}</td>
      <td>{cells.email}</td>
    </>
  );
}

StrictMode is a development only wrapper that surfaces unsafe patterns. In React 18 and later it deliberately double invokes renders, effects and state updater functions so that impure code and missing cleanup show up immediately.

• It renders nothing and has no effect on the production build.
• It mounts each component, unmounts it and mounts it again, so an effect without a cleanup function leaks visibly rather than silently.
• It calls render functions and state updaters twice, so a component that mutates something outside itself produces obviously wrong results.
• It warns about deprecated APIs such as legacy string refs and the unsafe lifecycle methods.

React gives you a reusable component model, a large ecosystem and predictable declarative updates. The trade-offs are that it is only the view layer, the ecosystem changes quickly, and a client rendered app needs extra work for SEO and first paint.

Advantages

• Components are reusable and testable in isolation.
• Declarative code is easier to reason about than imperative DOM manipulation.
• One of the largest ecosystems in front end: routing, data fetching, component libraries, tooling.
• The same mental model works for web, server rendering and native.

Limitations

• React only solves rendering. Routing, data fetching, forms and state management are decisions you have to make.
• The recommended way of doing things changes: classes to hooks, then to Server Components.
• JSX plus a build step is an extra layer for developers new to the stack.
• A purely client rendered app ships an empty HTML shell, which costs you first paint and can cost you crawlability.

A client rendered React app ships an almost empty HTML document, which is a handicap. You fix it by rendering on the server, with SSR or static generation through a framework such as Next.js, and by managing titles, descriptions, canonicals and structured data per route.

Google can execute JavaScript, but rendering is queued and not guaranteed for every crawl, and other crawlers and social scrapers often do not execute it at all. Sending real HTML removes the question entirely.

• Render on the server. Static generation for content that rarely changes, SSR for content that does.
• Give every route its own metadata. A unique title and description, and a self referencing canonical.
• Emit structured data. JSON-LD tells search engines and answer engines what the page is.
• Watch Core Web Vitals. Code split, keep the main bundle small, reserve space for images and ads so the layout does not shift.
• Use real links. A div with an onClick handler is not a link and is not crawlable.

Imperative code lists the steps to change the UI. Declarative code states what the UI should be for the current state and lets React work out the steps.

// Imperative: you own every transition
if (isLoading) {
  spinner.style.display = 'block';
  list.style.display = 'none';
} else {
  spinner.style.display = 'none';
  list.style.display = 'block';
}

// Declarative: you describe the end state
return isLoading ? <Spinner /> : <List items={items} />;

The imperative version has to handle every path between every pair of states, and the number of paths grows much faster than the number of states. The declarative version only ever describes one state at a time, which is why React apps stay manageable as the number of states grows.

No. The setter schedules a re-render. The state variable in the current render keeps its old value, and the new value is only visible in the next render.

const [count, setCount] = useState(0);

function handleClick() {
  setCount(count + 1);
  setCount(count + 1);
  console.log(count); // 0, not 1 and not 2
}
// count ends up 1, because both calls computed 0 + 1

Each render has its own count, captured as a constant. Both calls read the same 0. Pass a function to the setter when the next value depends on the previous one, and React applies them in order.

setCount((previous) => previous + 1);
setCount((previous) => previous + 1);
// count ends up 2

React also batches updates. Multiple setter calls inside one event handler produce a single re-render, and since React 18 that batching also applies inside promises, timeouts and native event handlers.