Stop Using React.FC: Modern TypeScript Patterns for Children Props

Here's the uncomfortable truth: if you're still using React.FC to type your React components, you're writing code that's harder to maintain, debug, and refactor. The React and TypeScript communities have moved on, and it's time you did too.

The real insight isn't just how to type children props—it's understanding why explicit typing beats magic helpers every time. Let me show you the modern patterns that will make your React+TypeScript code bulletproof.

The React.FC Problem Nobody Talks About

Most developers reached for React.FC because it seemed convenient:

1// The old way - looks clean but hides problems
2const Button: React.FC<{ color: string }> = ({ color, children }) => {
3  return <button style={{ color }}>{children}</button>;
4};

But here's what React.FC actually does to your code:

• Implicitly adds children even when you don't need it
• Breaks forwardRef patterns completely
• Hides your actual prop types from IDE tooling
• Makes generic components unnecessarily complex

The moment you need to forward refs or create wrapper components that match HTML semantics exactly, React.FC falls apart.

The Four Modern Patterns You Actually Need

Instead of one magic type, modern React+TypeScript uses targeted patterns for different use cases:

Pattern 1: Explicit ReactNode for Maximum Flexibility

For most components, be explicit about children:

1interface ModalProps {
2  isOpen: boolean;
3  onClose: () => void;
4  children: React.ReactNode; // Accepts JSX, strings, numbers, arrays, null
5}
6
7function Modal({ isOpen, onClose, children }: ModalProps) {
8  return isOpen ? (
9    <div className="modal">
10      <button onClick={onClose}>×</button>
11      {children}
12    </div>
13  ) : null;
14}

ReactNode is your Swiss Army knife—it accepts JSX elements, text, numbers, arrays, fragments, portals, and even null or undefined. Perfect for layouts, modals, and containers where you don't know what content will be passed.

Pattern 2: PropsWithChildren for Clean Extension

When you want to add children to existing props without repetition:

1interface ButtonBaseProps {
2  variant: 'primary' | 'secondary';
3  disabled?: boolean;
4  onClick: () => void;
5}
6
7// Automatically adds children: React.ReactNode
8type ButtonProps = React.PropsWithChildren<ButtonBaseProps>;

This pattern shines when you're building design systems or component libraries where consistent prop patterns matter.

Pattern 3: ComponentProps for HTML Wrapper Components

The secret weapon for components that need to behave exactly like native HTML elements:

1// Inherits ALL div props (className, style, onClick, etc.) + children
2type BorderProps = React.ComponentProps<'div'>;
3
4function Border({ children, className = '', ...props }: BorderProps) {
5  return (
6    <div 
7      className={`border-2 border-gray-300 ${className}`}
8      {...props}

This is perfect for wrapper components, styled containers, or any component that should accept all the props its underlying HTML element supports.

Pattern 4: ComponentPropsWithRef for Ref Forwarding

When you need refs AND full HTML compatibility:

1type InputProps = React.ComponentPropsWithRef<'input'>;
2
3const Input = React.forwardRef<HTMLInputElement, InputProps>(
4  ({ className = '', ...props }, ref) => {
5    return (
6      <input
7        ref={ref}
8        className={`form-input ${className}`}

This combination handles the most complex case: components that need to forward refs while maintaining full HTML element compatibility.

Making the Migration Painless

If you're working with an existing codebase, here's your step-by-step refactor checklist:

1. Find and replace: Search for React.FC and React.FunctionComponent

2. Convert systematically: Start with leaf components (buttons, inputs) before containers

3. Add explicit children: Define children?: React.ReactNode only where actually used

4. Test ref patterns: If you use forwardRef anywhere, switch to ComponentPropsWithRef

5. Enable strict mode: Add "strict": true to your tsconfig.json and fix the warnings

Here's a before/after for a common component:

1// Before - implicit and inflexible
2const Card: React.FC<{ title: string }> = ({ title, children }) => (
3  <div className="card">
4    <h2>{title}</h2>
5    {children}
6  </div>
7);
8

Why This Matters Right Now

Type safety isn't just about preventing crashes—it's about developer experience and maintainability. With explicit children typing:

• Your IDE gives you accurate autocompletion and error detection
• Refactoring becomes safe and predictable
• New team members can understand component contracts immediately
• Generic components scale without mysterious type errors

In large codebases, this can reduce React-related bugs by 15-20% according to teams that've made the migration. But more importantly, it makes your code readable and intentional.

The web is moving toward stricter TypeScript configurations, and implicit patterns like React.FC are becoming liability. Start typing your children props explicitly today, and your future self will thank you when you're debugging complex component hierarchies at 2 AM.

Next step: Pick one component in your current project and refactor it using these patterns. Start with ReactNode for simple cases, then experiment with ComponentProps for your wrapper components. The muscle memory you build now will pay dividends across every React project you touch.