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

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-types
type checking
validation
development

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

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

The solution is hidden so you can try first

6 min read · 9 sections

Try it in the playground

Open any example in the playground to run and change it.

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

Open in 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>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.