Case styles, props, state, handlers, and file naming for React and TypeScript in LAD-aligned codebases

LAD naming conventions

This page describes naming conventions for React and TypeScript code: components, hooks, props, handlers, and related identifiers. It complements structural rules in Quick start and patterns in the Design patterns guide.

Entity	Convention	Example	Rationale
Components	PascalCase	UserProfile, ShoppingCart	Distinguishes them from regular HTML elements.
Interfaces/Types	PascalCase	ExampleItem, UserProfile	Matches component and class naming; treats types as nominal entities.
Files	kebab-case or lowercase	user-profile.js, my-component.tsx	Prevents conflicts on case-insensitive file systems and improves readability. (Note: some projects use PascalCase for files to match the component name)
Functions/Variables	camelCase	fetchUserData, userName	Standard JavaScript practice.
Custom Hooks	camelCase prefixed with `use`	useFetchData, useOnlineStatus	Required by React to enforce "Rules of Hooks".
Constants	UPPER_SNAKE_CASE	MAX_HEIGHT, API_KEY	Makes constants easily identifiable as unchanging values.
Props	camelCase	imageSrc, isLoading, onRemove	Follows standard JavaScript attribute naming. Boolean props often use `is` or `has` prefixes (e.g., isVisible).
Event Handlers	camelCase with `handle` prefix	handleSubmit, handleClick, handleLogout, handleInputChange	Use the `handle` prefix and camelCase for event handlers to clearly indicate their purpose and ensure consistency in React naming.
Folders	kebab-case or lowercase	user-profile, utils, components	Enhances readability and consistency with file paths.

Functions

Function names are case-sensitive and should start with a lowercase letter. Use camelCase for naming. Prefer meaningful names and typically use imperative verbs.

✔️ Good	❌ Avoid
`getUserData`	`UserData`
`fetchOrders`	`FetchOrders`

// ✔️
const getUserData = () => {
  // function implementation
  return userData;
};

const fetchOrders = () => {
  // function implementation
  return orders;
};

// ❌
const UserData = () => {
  // function implementation
  return userData;
};

const FetchOrders = () => {
  // function implementation
  return orders;
};

Interfaces and types

TypeScript interfaces and type aliases should use PascalCase.

✔️ Good	❌ Avoid
`ExampleItem`	`exampleItem`

// ✔️
interface ExampleItem {
  id: number;
  name: string;
}

type UserProfile = {
  id: string;
  email: string;
};

// ❌
interface exampleItem {
  id: number;
  name: string;
}

State variables

For boolean state variables, prefix them with is, has, or should.

✔️ Good	❌ Avoid
`isActive`, `setIsActive`	`active`, `setActive`
`hasError`, `setHasError`	`error`, `setError`
`shouldRender`, `setShouldRender`	`render`, `setRender`

import { useState } from "react";

const ExampleComponent = () => {
  const [isActive, setIsActive] = useState(true); // ✔️
  const [hasError, setHasError] = useState(false); // ✔️
  const [shouldRender, setShouldRender] = useState(true); // ✔️

  // const [active, setActive] = useState(true); // ❌
  // const [error, setError] = useState(false); // ❌
  // const [render, setRender] = useState(true); // ❌

  const handleClick = () => {
    setIsActive(!isActive);
  };

  return (
    <div>
      {shouldRender && (
        <div className={isActive ? "active" : "inactive"}>
          <button onClick={handleClick}>{isActive ? "active" : "inactive"}</button>
          {hasError && <p>An error occurred.</p>}
        </div>
      )}
    </div>
  );
};

export default ExampleComponent;

By following this convention, the purpose and meaning of boolean state variables become clearer, making the code more readable and maintainable.

Prop types by value

Type	Convention	Example
Array	Plural nouns	`items`
Number	Prefix `num` or postfix `count`, `index`	`numItems`, `itemCount`, `itemIndex`
Bool	Prefix `is`, `can`, or `has` (see below)	`isVisible`, `canToggle`, `hasHeader`
Object	Noun	`item`
Node	Prefix `node`	`containerNode`
Element	Prefix `element`	`hoverElement`

Bool prefix usage

is — visual/behavior variations. e.g. isVisible, isEnabled, isActive
can — behavior or conditional visual variations. e.g. canToggle, canExpand, canHaveCancelButton
has — toggling UI elements. e.g. hasCancelButton, hasHeader

Name props to describe the component itself

Avoid naming props after the current user or environment.

❌ Avoid: naming after user or environment

Wrong	Better	Reason
`hasSubmitPermission`	`hasSubmitButton`	Describes permission, not the component
`isMobileScreen`	`isCompactLayout`	Describes viewport, not the layout variant

<MyForm hasSubmitButton={user.canSubmit} />
<MyForm isCompactLayout={browser.isMobileScreen} />

❌ Avoid: naming after children instead of the component

Wrong	Better
`onClick`	`onItemClick`
`areCommentsLoading`	`isLoadingComments`
`hasIcon`	`isSpacious`

When you want more room for content rather than toggling an icon, use isSpacious instead of hasIcon — the latter answers "why", not "what".

<MyList onItemClick={...} />

Event handler props

Convention	Use for	Example
`on` prefix	Prop names	`onSelect`, `onClick`
`handle` prefix	Handler functions	`handleClick`, `handleChange`

<MyComp onClick={this.handleClick} />

Tip: Avoid built-in event handler prop names for custom events. Use onSelect instead of onFocus or onClick when the native event is not of interest.

Naming conventions