How to pass props to a component in React

Props, short for properties, are a fundamental concept in React that allow you to pass data from one component to another. They serve as a way to configure components, making them reusable and adaptable to various contexts. When you think about it, props are like the parameters you provide to a function, but they do something more: they help maintain the unidirectional data flow that React is famous for.

One of the best practices is to treat props as immutable inside the component. This means that you shouldn’t try to change the props directly. Instead, if you find yourself needing to manipulate data, consider using state or lifting the state up to a common ancestor component. This keeps your components predictable and easier to debug.

For example, when defining a functional component, you can access props directly as an argument:

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

Here, the Greeting component receives name as a prop and renders a greeting message. You can invoke this component like this:

<Greeting name="Alice" />

This would render “Hello, Alice!” on the screen. You can pass multiple props as well, which allows components to be highly customizable:

<Greeting name="Alice" age={30} location="Wonderland" />

In this case, you could further enhance the Greeting component to accept and display age and location if desired, making it even more versatile.

When working with class components, props are accessed slightly differently. You use the this keyword to refer to the component instance, which gives you access to props:

class Greeting extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

By using props, you can create a clear contract of what data your components need, which is crucial for maintaining a clean architecture. This also leads to better collaboration among developers, as everyone can understand how components interact with one another through their defined interfaces.

Additionally, one way to ensure that your components are receiving the correct type and shape of props is by using prop types. This is an essential practice that can save you time and headaches during development.

Defining and passing props to functional components

To use prop types, you first need to install the prop-types package, as it was separated from the core React library a while back. You’d run npm install prop-types or yarn add prop-types. Once installed, you import it into your component file and attach a special propTypes property to your component.

Let’s take a UserProfile component. We expect a name (string), age (number), and whether the user is active (boolean). Here’s how you’d enforce that:

import React from 'react';
import PropTypes from 'prop-types';

function UserProfile(props) {
  return (
    <div>
      <p>Name: {props.name}</p>
      <p>Age: {props.age}</p>
      <p>Status: {props.isActive ? 'Active' : 'Inactive'}</p>
    </div>
  );
}

UserProfile.propTypes = {
  name: PropTypes.string,
  age: PropTypes.number,
  isActive: PropTypes.bool
};

Now, if someone tries to use your component and passes a number for the name, like , React won’t crash the application. Instead, it will log a very helpful warning in the developer console during development. This is invaluable because it catches bugs early, right where they happen, instead of letting bad data propagate through your component tree and cause some mysterious error ten levels down.

You can get much more specific. You can mark props as required, and you can define the shape of object props. If a user’s name is absolutely essential for the component to render correctly, you should mark it as required. Let’s also say we want to pass a structured contactInfo object.

UserProfile.propTypes = {
  name: PropTypes.string.isRequired,
  age: PropTypes.number,
  isActive: PropTypes.bool,
  contactInfo: PropTypes.shape({
    email: PropTypes.string.isRequired,
    phone: PropTypes.string
  })
};

Using PropTypes.shape is far better than just PropTypes.object because it validates the *contents* of the object. It ensures that contactInfo is an object and that it contains an email key with a string value. This self-documentation is a lifesaver on large teams where you can’t possibly remember the expected data structure for every single component.

What about optional props? If a prop isn’t marked as isRequired, its value will be undefined if it’s not passed. This can lead to unexpected behavior or errors, like trying to render undefined. To prevent this, you can provide default values for props using another special property, defaultProps.

This ensures that if a prop is omitted, the component still has a sensible value to work with. For our UserProfile, we could set a default for isActive.

UserProfile.defaultProps = {
  age: 21,
  isActive: false,
  contactInfo: {
    email: '[email protected]'
  }
};

When you define defaultProps, React will use these values for any props that are passed as undefined. This includes props that were not passed at all. It’s important to note that defaultProps are resolved before propTypes are checked, so your default values will also be validated against their type definitions. This mechanism works for both functional and class components, though the syntax for defining them on class components is slightly different, using a static class field. For example, you can also pass functions as props, which is a common pattern for child components to communicate back to their parents. You would validate this using PropTypes.func. This pattern, often called “lifting state up”, is central to building complex React applications where state needs to be shared among siblings. A parent component defines a function and passes it down to a child component via props. The child can then call this function to notify the parent of an event, like a button click.

Handling props in class components

While functional components receive props as a function argument, class components access them through the instance property this.props. This object is available anywhere inside your class methods, including the render method, the constructor, and all the lifecycle methods. When the parent component re-renders with new props for your class component, React updates this.props and triggers a re-render.

Just like with functional components, defining propTypes and defaultProps on class components is a non-negotiable part of writing robust code. The modern and most common way to do this is by using static class fields. This keeps the prop definitions right inside the component class, which is great for co-location and readability.

import React from 'react';
import PropTypes from 'prop-types';

class UserCard extends React.Component {
  static propTypes = {
    userId: PropTypes.number.isRequired,
    theme: PropTypes.oneOf(['light', 'dark']),
    onSelect: PropTypes.func
  };

  render() {
    const { userId, theme } = this.props;
    const cardClass = card theme-${theme};
    return (
      <div className={cardClass}>
        User ID: {userId}
      </div>
    );
  }
}

This is much cleaner than attaching the propTypes object to the class after its definition, like UserCard.propTypes = {...}. It makes the component a self-contained unit. Here, we’re saying that userId is a mandatory number, and theme must be one of two specific strings. If you pass theme="blue", you’ll get a warning in your console. This is exactly the kind of immediate feedback you want.

Similarly, you can define default props using a static field. This ensures your component doesn’t break if an optional prop isn’t provided. Let’s give our UserCard a default theme and a no-op function for onSelect so we don’t have to check if it exists before calling it.

class UserCard extends React.Component {
  static propTypes = {
    userId: PropTypes.number.isRequired,
    theme: PropTypes.oneOf(['light', 'dark']),
    onSelect: PropTypes.func
  };

  static defaultProps = {
    theme: 'light',
    onSelect: () => {} // A sensible default for a function prop
  };

  // ... render method from before
  render() {
    // ...
  }
}

A key area where class components differ from functional components (pre-Hooks) is in handling side effects when props change. Lifecycle methods like componentDidUpdate are the right place for this. This method receives the previous props and state as arguments, allowing you to compare the new props with the old ones. This comparison is critical; without it, you could easily create an infinite loop of updates and API calls.

For instance, if your component needs to fetch data based on a prop like userId, you should only re-fetch that data if the userId has actually changed.

class UserProfileData extends React.Component {
  state = {
    userData: null,
    loading: true
  };

  componentDidMount() {
    this.fetchData(this.props.userId);
  }

  componentDidUpdate(prevProps) {
    // Crucial check: only fetch if the userId prop has changed!
    if (this.props.userId !== prevProps.userId) {
      this.fetchData(this.props.userId);
    }
  }

  fetchData = (userId) => {
    this.setState({ loading: true });
    // Imagine fetchUser is a function that returns a promise
    fetchUser(userId)
      .then(userData => {
        this.setState({ userData, loading: false });
      });
  };

  render() {
    // ... render loading state or user data
  }
}

This pattern is fundamental to working with class components that manage their own data fetching. The check this.props.userId !== prevProps.userId prevents the component from re-fetching on every single render, which could be triggered by a parent component for reasons completely unrelated to the userId. Forgetting this check is a common source of bugs and performance problems in class-based React apps.

Prop validation for better code quality

While we’ve covered the essentials, the prop-types library has more tricks up its sleeve for defining even more precise component contracts. For instance, what if your component expects an array of users, where each user is an object with a specific structure? You can’t just use PropTypes.array; that’s lazy and unhelpful. The correct tool here is PropTypes.arrayOf, which you can combine with PropTypes.shape to validate the structure of each element in the array.

import PropTypes from 'prop-types';

function UserList({ users }) {
  return (
    <ul>
      {users.map(user => <li key={user.id}>{user.name}</li>)}
    </ul>
  );
}

UserList.propTypes = {
  users: PropTypes.arrayOf(PropTypes.shape({
    id: PropTypes.number.isRequired,
    name: PropTypes.string.isRequired
  })).isRequired
};

This is a solid contract. It tells any developer using UserList that they must pass an array, and that array must contain objects, and each object must have a number id and a string name. Anything else will trigger that helpful console warning. Other useful validators include PropTypes.objectOf for objects with values of a certain type, PropTypes.element for when a prop should be a React element, and PropTypes.node, which is the most flexible type, accepting anything React can render: numbers, strings, elements, or even an array of nodes. It’s the standard choice for validating the children prop.

import PropTypes from 'prop-types';

function Card({ children, title }) {
  return (
    <div className="card">
      <h2 className="card-title">{title}</h2>
      <div className="card-body">
        {children}
      </div>
    </div>
  );
}

Card.propTypes = {
  title: PropTypes.string.isRequired,
  children: PropTypes.node
};

For truly specific constraints, you can even write your own custom validation function. The function will receive the full props object, the name of the prop you’re validating, and the component’s name. If the validation fails, you simply return an Error object. This is useful for cases where the validity of one prop depends on another, or when you need to enforce a format that can’t be expressed with the built-in types.

CustomComponent.propTypes = {
  customProp: function(props, propName, componentName) {
    if (!/matchme/.test(props[propName])) {
      return new Error(
        'Invalid prop ' + propName + ' supplied to' +
        ' ' + componentName + '. Validation failed.'
      );
    }
  }
};

However, it’s impossible to talk about prop validation in modern React without discussing TypeScript. For many teams, especially on larger projects, TypeScript has made prop-types largely obsolete. The key difference is *when* the check happens. Prop types are checked at runtime, in the browser, during development. TypeScript checks types at compile-time, in your code editor, before the code is ever run. This is a monumental difference in workflow.

With propTypes, the feedback loop involves writing code, running the app, interacting with it, and then checking the developer console for warnings. With TypeScript, you get immediate feedback as you type. If you try to pass a string to a prop that expects a number, your editor will immediately highlight the error. It’s like having a linter on steroids that understands your entire codebase and how all the pieces are supposed to fit together.

Let’s rewrite our UserCard component from earlier using TypeScript. Instead of a propTypes object, we define a type or interface for the props.

import React from 'react';

type UserCardProps = {
  userId: number;
  theme?: 'light' | 'dark';
  onSelect?: () => void;
};

const UserCard: React.FC<UserCardProps> = ({ 
  userId, 
  theme = 'light', 
  onSelect = () => {} 
}) => {
  const cardClass = card theme-${theme};
  
  return (
    <div className={cardClass} onClick={onSelect}>
      User ID: {userId}
    </div>
  );
};

This code is not only self-documenting but also safer. Your editor will now provide autocompletion for the props when you use the UserCard component. If you try to pass theme="blue", TypeScript will throw a compile-time error. While there’s a learning curve and setup cost to adopting TypeScript, it eliminates entire categories of runtime errors, makes refactoring safer, and dramatically improves the developer experience on any application that’s more complex than a simple to-do list.