React Mastery: Mastering Prop Type Generation

JSON to React Props: Generating TypeScript Interfaces and Component Scaffolds

When building React components that display or manipulate API data, you need a TypeScript interface for the props and a component skeleton to start from. Writing these by hand for every API endpoint means copying field names, inferring types, and deciding which props are optional — all before writing any actual UI code. Generating React props from JSON skips that ceremony and gives you a typed interface plus a working component scaffold in seconds.

Live Example: Product Card Component

// Input JSON (API response for a product)
{
  "id": "prod_881",
  "name": "TypeScript Handbook",
  "price": 29.99,
  "in_stock": true,
  "category": "books",
  "thumbnail": "https://cdn.example.com/books/ts-handbook.jpg",
  "rating": null
}

// Generated Output
import React from 'react';

export interface ProductProps {
  id: string;
  name: string;
  price: number;
  in_stock: boolean;
  category: string;
  thumbnail: string;
  rating?: number;
}

export const Product: React.FC<ProductProps> = (props) => {
  return (
    <div className="p-4 rounded-xl border border-slate-200 dark:border-slate-800">
      <h2 className="text-xl font-bold mb-2">Product</h2>
      <ul className="space-y-1 text-sm text-slate-600 dark:text-slate-400">
        <li><strong>id:</strong> {String(props.id ?? '')}</li>
        <li><strong>name:</strong> {String(props.name ?? '')}</li>
        ...
      </ul>
    </div>
  );
};

Refining the Generated Interface

The generated interface is structurally correct but uses broad types. Tighten it for your actual use case:

// Generated (broad types)
export interface ProductProps {
  id: string;
  category: string;
  rating?: number;
}

// Refined (specific types)
export interface ProductProps {
  id: `prod_${string}`;                       // branded string
  category: 'books' | 'software' | 'courses'; // literal union
  rating?: 1 | 2 | 3 | 4 | 5;               // constrained number
}

Optional vs Required Props Patterns

The generator marks props as optional (?) when the field is null in your JSON sample. Review these — a null value in sample data doesn't always mean the prop should be optional in the component contract:

// When a prop has a sensible default, use defaultProps or default parameter
export interface CardProps {
  title: string;
  subtitle?: string;        // genuinely optional — component renders fine without it
  variant?: 'default' | 'featured';
}

// With default values in function signature (preferred in modern React)
export const Card = ({
  title,
  subtitle,
  variant = 'default',
}: CardProps) => {
  return (
    <div data-variant={variant}>
      <h2>{title}</h2>
      {subtitle && <p>{subtitle}</p>}
    </div>
  );
};

Extending with HTML Attributes

Components that wrap native elements should forward HTML attributes. Extend the generated interface to allow passthrough:

import React from 'react';

export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  label: string;
  loading?: boolean;
  variant?: 'primary' | 'secondary' | 'destructive';
}

export const Button = ({ label, loading, variant = 'primary', ...rest }: ButtonProps) => (
  <button
    {...rest}   // passes through onClick, disabled, type, aria-*, etc.
    disabled={loading || rest.disabled}
    data-variant={variant}
  >
    {loading ? 'Loading...' : label}
  </button>
);

React.FC vs Plain Function Declaration

The generator uses React.FC<Props>. This is a style choice with a known tradeoff:

• React.FC: Explicitly marks the function as a component. Previously included children in the type automatically (removed in React 18's type definitions).
• Plain function: function Product(props: ProductProps) {} or const Product = (props: ProductProps) => {} — preferred by many teams for being less verbose and more consistent with regular TypeScript functions.

Both are valid. Most modern style guides and the React team's own docs lean toward plain function declarations. Swap React.FC<Props> for a plain function signature if your team prefers it.

Frequently Asked Questions

How does it handle nested objects? Nested JSON objects become Record<string, any> in the generated props. For production code, extract the nested object into its own interface and reference it by name.

What about the children prop? The generator doesn't add children automatically. Add children?: React.ReactNode to the interface if the component needs to render slot content.

Should I use this for every component? Best suited for data-display components built directly on top of an API response shape. For purely presentational components, design the props interface first and derive the data shape from it — not the other way around.

Is my JSON sent to a server? No. TypeMorph runs entirely in your browser — API response samples often contain real user data, and none of it leaves your machine.