What is `PropTypes` and when would you use it? | Interview Question

Q: What is `PropTypes` and when would you use it?

**Target Audience:** Engineers preparing for React interviews — assumes basic component knowledge. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . This topic has a genuine breaking change behind it, so the central claim below was verified by actually rendering a component with propTypes on React 19.2.8 and by checking the React upgrade guide — not recalled. ## 1. Why This Even Matters — A Story First Think of a parcel depot. **PropTypes** was a clerk who opened each parcel *after* it arrived, checked whether the contents matched the label, and — if not — wrote a complaint in a logbook nobody was required to read. The parcel went out for delivery regardless. **TypeScript** is a rule at the loading bay: a mislabelled parcel never gets on the van in the first place. Once the second option exists, the first is hard to justify. React eventually agreed, and in React 19 the cle

01

Understand the problem

Question presented to candidate: "What is PropTypes, and when would you reach for it today?"

What a strong answer should cover:

PropTypes was React's runtime prop type-checking mechanism: attach a propTypes object and React warns in the console when a prop has the wrong type.
It ran in development only and was always a warning, never an error — it never blocked a render.
The history matters: React.PropTypes moved out to the standalone prop-types package in React 15.5.
The key fact: React 19 removed propType checking entirely. A propTypes object on a component is now silently ignored — no validation, no warning.
defaultProps was likewise removed for function components in React 19, in favour of ES6 default parameters. Class components keep it.
So the honest answer to "when would you use it" is: not in new code. Use TypeScript, which catches the same errors at compile time and across the whole call site.
The remaining niche: validating data crossing a runtime boundary — API responses, plugin inputs — which is a job for Zod or Valibot, not PropTypes.

Clarifying questions expected:

"Which React version is this codebase on?" — the answer changes completely at 19.
"Is the project on TypeScript already?"

Code / implementation expected: Optional. Showing the TypeScript and default-parameter replacement for a propTypes + defaultProps pair is the useful version.

prop-typestype checkingvalidationdevelopment

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for React interviews — assumes basic component knowledge. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. This topic has a genuine breaking change behind it, so the central claim

Solution ready — 2 min read

Classified // press E to declassify

04

Explore the playground snippets

Verifying propTypes is inert on React 19, and the modern replacement

Run Playground

import { useState } from "react";

// ── The legacy pattern ─────────────────────────────────────────────────────
// A validator designed to scream if it is ever called. On React 19 it is not.
let validatorCalls = 0;
function LegacyGreeting({ name, age }) {
  return <p>{name} is {age}</p>;
}
LegacyGreeting.propTypes = {
  name: () => { validatorCalls += 1; return new Error("name is wrong!"); },
  age:  () => { validatorCalls += 1; return new Error("age is wrong!"); },
};
// Also removed for function components in React 19 — silently stops applying.
LegacyGreeting.defaultProps = { age: 99 };

// ── The modern replacement ─────────────────────────────────────────────────
// Default values are plain ES6 default parameters, readable right where the
// prop is destructured. In a .tsx file the types would live here too:
//   function ModernGreeting({ name, age = 99 }: { name: string; age?: number })
function ModernGreeting({ name, age = 99 }) {
  return <p>{name} is {age}</p>;
}

export default function App() {
  const [checked, setChecked] = useState(false);

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6 }}>
      <h4>Legacy — propTypes attached, deliberately wrong props passed</h4>
      {/* name should be a string, age a number: both are wrong on purpose */}
      <LegacyGreeting name={12345} age="not a number" />
      {/* A div, not a p: LegacyGreeting renders a <p> of its own, and a p
          inside a p is invalid HTML the browser silently repairs. */}
      <div>defaultProps age fallback: <LegacyGreeting name="Ada" /></div>

      <h4>Modern — ES6 default parameter</h4>
      <ModernGreeting name="Ada" />

      <button onClick={() => setChecked(true)}>Check whether validators ran</button>
      {checked && (
        <p style={{ marginTop: 12, padding: 12, background: "#fff3cd", borderRadius: 6 }}>
          propTypes validators called: <strong>{validatorCalls}</strong>
          {validatorCalls === 0
            ? " — React 19 ignores propTypes entirely. No warning, no validation."
            : " — this React version still honours propTypes."}
          <br />
          Notice too that the legacy defaultProps age fallback did not apply,
          while the ES6 default parameter did.
        </p>
      )}
    </div>
  );
}

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.