React Component Naming Conventions: A Practical Guide

When you build an internal support dashboard, component names often start simple: card, list, data, and button. A few weeks later, the same React application has dozens of files, several API requests, filters, forms, and team members trying to understand what each component does.

That is where clear React component naming conventions make a real difference. Good names reduce review time, make debugging easier, and help you reuse the right UI without opening every file.

This reference guide shows how to name React components, props, event handlers, hooks, files, and folders using a practical employee directory example.

Why React Component Naming Conventions Matter

A component is a reusable JavaScript function that returns JSX, the HTML-like syntax React uses to describe a user interface. In a browser-based React application, component names tell React whether it should treat a tag as a built-in HTML element or a custom component.

For example, React reads <section> as a normal HTML element. It reads <EmployeeCard /> as a custom React component.

Clear names also show intent. Compare these two imports:

import Card from "./Card";
import List from "./List";
import Data from "./Data";

Now compare them with this version:

import EmployeeDirectory from "./EmployeeDirectory";
import EmployeeCard from "./EmployeeCard";
import EmployeeSearchInput from "./EmployeeSearchInput";

The second version explains the screen before you even read the code. This becomes especially useful when you are working on a larger application with shared UI, API integration, and several routes.

If you are still getting comfortable with how components receive values, review this guide on props in React. It helps you see why a component name and its props should describe one clear responsibility.

Use PascalCase for React Components

The main React component naming rule is simple: use PascalCase.

PascalCase means every word starts with a capital letter, with no spaces or hyphens.

function EmployeeCard() {
  return <article>Employee details</article>;
}

function SupportTicketList() {
  return <section>Open support tickets</section>;
}

function SalesSummaryPanel() {
  return <aside>Monthly sales summary</aside>;
}

Each component starts with a capital letter, so React recognizes it as a custom component.

Avoid lowercase component names

This code looks harmless but causes a common React problem:

function employeeCard() {
  return <article>Employee details</article>;
}

export default function EmployeeDirectory() {
  return <employeeCard />;
}

React treats <employeeCard /> like an unknown HTML element, not like the employeeCard function. The browser may render a custom lowercase tag instead of running your component.

Write it this way instead:

function EmployeeCard() {
  return <article>Employee details</article>;
}

export default function EmployeeDirectory() {
  return <EmployeeCard />;
}

The EmployeeCard function and <EmployeeCard /> JSX tag now match. This is also why consistent capitalization matters when you import a component from another file.

For a closer look at this rule and common capitalization errors, see React component capitalization rules.

Name Components by Their Job

The best React component names explain what users see or what the component does. Avoid vague names such as Box, Item, Data, Main, or Component unless they are truly generic shared UI pieces.

In an employee directory, these names are easier to maintain:

Unclear name	Better name	Why it helps
Card	EmployeeCard	Shows the data displayed in the card
List	EmployeeList	Explains which items the list renders
Form	EmployeeSearchForm	Shows the form’s purpose
Modal	EmployeeDetailsModal	Identifies the content in the dialog
Header	DirectoryHeader	Distinguishes it from other page headers
Button	DeleteEmployeeButton	Makes its action obvious

A good rule is to use this pattern:

Domain + UI role

Examples include:

• EmployeeTable
• TicketStatusBadge
• ProductFilterPanel
• CustomerProfileForm
• InvoiceDownloadButton

This approach works well in business applications because the domain word gives important context. A StatusBadge may be reusable across the whole application. A TicketStatusBadge is more specific and easier to locate when you are fixing the support dashboard.

Build a Clear Component Tree

Let’s use a small employee directory that runs in a React frontend. The screen loads employee data, allows a user to search names, and renders matching cards.

Start by giving each layer a meaningful name:

import { useState } from "react";
import EmployeeSearchInput from "./EmployeeSearchInput";
import EmployeeList from "./EmployeeList";

const employees = [
  { id: 1, name: "Aisha Khan", department: "Sales" },
  { id: 2, name: "Daniel Lee", department: "Engineering" },
  { id: 3, name: "Priya Shah", department: "Human Resources" }
];

export default function EmployeeDirectoryPage() {
  const [searchTerm, setSearchTerm] = useState("");

  const visibleEmployees = employees.filter((employee) =>
    employee.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <main>
      <h1>Employee Directory</h1>

      <EmployeeSearchInput
        searchTerm={searchTerm}
        onSearchTermChange={setSearchTerm}
      />

      <EmployeeList employees={visibleEmployees} />
    </main>
  );
}

This component is named EmployeeDirectoryPage because it represents a full route or screen. It manages state using useState, a React hook that stores values between renders. The variable searchTerm clearly describes the stored value, while visibleEmployees explains that it contains filtered results.

The child component names show their exact roles. EmployeeSearchInput collects the search text, and EmployeeList renders the results.

Name presentational components clearly

A presentational component mainly displays UI from its props. EmployeeCard is a good example.

export default function EmployeeCard({ employee }) {
  return (
    <article className="employee-card">
      <h2>{employee.name}</h2>
      <p>{employee.department}</p>
    </article>
  );
}

This component accepts one employee prop and displays it. Naming it EmployeeCard is stronger than naming it Card, because a future developer knows its content without inspecting the file.

import EmployeeCard from "./EmployeeCard";

export default function EmployeeList({ employees }) {
  if (employees.length === 0) {
    return <p>No employees match your search.</p>;
  }

  return (
    <section className="employee-list">
      {employees.map((employee) => (
        <EmployeeCard key={employee.id} employee={employee} />
      ))}
    </section>
  );
}

EmployeeList owns the list rendering logic. It uses conditional rendering, which means React shows different JSX depending on a condition. If no employee matches the search, users see a useful message instead of a blank screen.

The key uses the employee’s stable id. React uses keys to track which list item changed, was added, or was removed.

Name Props After the Data They Carry

Props are values passed from a parent component to a child component. Name props after what they contain, not after generic terms like data, value, or thing.

This is difficult to read:

<EmployeeCard data={employee} />
<EmployeeList items={visibleEmployees} />

It works, but data could mean almost anything. A more readable version is:

<EmployeeCard employee={employee} />
<EmployeeList employees={visibleEmployees} />

Use singular names for one object and plural names for collections:

<EmployeeCard employee={employee} />
<EmployeeList employees={employees} />
<DepartmentFilter departments={departments} />

For Boolean props, use a name that reads like a true-or-false statement:

<EmployeeCard isSelected={true} />
<EmployeeDetailsModal isOpen={false} />
<EmployeeList hasMoreResults={true} />

Avoid unclear Boolean names such as active, show, or open when the surrounding context is missing. isDetailsModalOpen is often clearer than open.

Name Event Handler Props With on

An event handler is a function that runs after a user action, such as clicking a button or typing in an input. For props that receive event handlers, use the on prefix.

export default function EmployeeSearchInput({
  searchTerm,
  onSearchTermChange
}) {
  return (
    <label>
      Search employees
      <input
        type="search"
        value={searchTerm}
        onChange={(event) => onSearchTermChange(event.target.value)}
        placeholder="Enter an employee name"
      />
    </label>
  );
}

The prop onSearchTermChange makes its purpose clear: the parent component will handle a change to the search term. This is more descriptive than a name like update, handler, or setValue.

Use these practical patterns:

Purpose	Recommended name
Click handler prop	onClick, onSave, onDelete
Input change handler prop	onSearchTermChange, onDepartmentChange
Form submit handler prop	onSubmit, onEmployeeCreate
Item selection handler prop	onEmployeeSelect, onTicketOpen
Local handler function	handleSave, handleDelete, handleSearchChange

Here is the parent component using a named local handler:

import { useState } from "react";
import EmployeeSearchInput from "./EmployeeSearchInput";
import EmployeeList from "./EmployeeList";

export default function EmployeeDirectoryPage() {
  const [searchTerm, setSearchTerm] = useState("");

  function handleSearchTermChange(nextSearchTerm) {
    setSearchTerm(nextSearchTerm);
  }

  const visibleEmployees = employees.filter((employee) =>
    employee.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <main>
      <h1>Employee Directory</h1>

      <EmployeeSearchInput
        searchTerm={searchTerm}
        onSearchTermChange={handleSearchTermChange}
      />

      <EmployeeList employees={visibleEmployees} />
    </main>
  );
}

I executed the above example code and added the screenshot below.

handleSearchTermChange describes a local function that handles the change. onSearchTermChange describes a callback prop that the child invokes. Keeping this distinction is a small habit that makes component communication much easier to follow.

For more examples of passing interactions through components, see how to handle events in React and passing a function to a child component.

Pro Tip: In my experience, do not rename every callback to onClick. A button inside EmployeeCard may use onClick, but the component’s public prop should usually reveal the business action, such as onEmployeeSelect or onEmployeeDelete.

Name Hooks and State Clearly

Hooks are React functions that let functional components use features such as state, effects, and shared logic. Built-in hooks use names like useState and useEffect. Your custom hooks should always start with use.

For example, a custom hook that loads directory employees should be called useEmployees, not getEmployees or loadData.

import { useEffect, useState } from "react";

export function useEmployees() {
  const [employees, setEmployees] = useState([]);
  const [isLoading, setIsLoading] = useState(true);
  const [errorMessage, setErrorMessage] = useState("");

  useEffect(() => {
    async function loadEmployees() {
      try {
        const response = await fetch("/api/employees");

        if (!response.ok) {
          throw new Error("Unable to load employees.");
        }

        const employeeData = await response.json();
        setEmployees(employeeData);
      } catch (error) {
        setErrorMessage(error.message);
      } finally {
        setIsLoading(false);
      }
    }

    loadEmployees();
  }, []);

  return { employees, isLoading, errorMessage };
}

I executed the above example code and added the screenshot below.

This hook runs an API request in useEffect. useEffect handles work outside rendering, such as fetching data after the component first appears. The names isLoading and errorMessage make UI states easy to understand.

Use these state naming patterns:

• employees and setEmployees
• selectedEmployee and setSelectedEmployee
• isLoading and setIsLoading
• errorMessage and setErrorMessage
• searchTerm and setSearchTerm

Avoid state names such as flag, status, temp, or result unless their meaning is obvious.

import EmployeeList from "./EmployeeList";<