Components & Props

A component is a JavaScript function that takes one argument — an object of props — and returns what to render: JSX, a string, a number, null, or an array of those. Components are how you split a UI into pieces you can name, reuse and reason about one at a time. <Greeting name="Rohit" /> reads like an HTML tag, but it means "React, call Greeting with { name: "Rohit" } and put whatever it returns here".

The mental model: a component is a recipe, and React is the cook. You write the recipe once; React decides when to follow it (on first render and whenever its inputs change) and what to do with the dish. You never call the recipe yourself, and a recipe never reaches into the kitchen to change things — given the same ingredients it produces the same dish. That last part is React's purity rule: rendering must be pure. Side effects (requests, timers, DOM changes) belong in event handlers and effects, not in the function body.

function Avatar({ name, size }) {
  return (
    <img
      src={`/avatars/${name}.png`}
      alt={name}
      width={size}
      height={size}
    />
  );
}

export function Greeting({ name }) {
  return (
    <div className="greeting">
      <Avatar name={name} size={40} />
      <p>Hello, {name}!</p>
    </div>
  );
}

export function App() {
  return (
    <>
      <Greeting name="Rohit" />
      <Greeting name="Asha" />
    </>
  );
}

// <App /> renders:
// <div class="greeting"><img alt="Rohit" width="40" height="40" src="/avatars/Rohit.png"><p>Hello, Rohit!</p></div>
// <div class="greeting"><img alt="Asha" width="40" height="40" src="/avatars/Asha.png"><p>Hello, Asha!</p></div>

The rules every function component follows:

• Name starts with a capital letter. JSX compiles <Greeting /> to a reference to the Greeting variable but <greeting /> to the string "greeting". A lowercase component renders an unknown HTML element instead, and React warns: "The tag <greeting> is unrecognized in this browser. If you meant to render a React component, start its name with an uppercase letter."
• Returns one thing: one element (use a fragment for siblings), null for nothing, a string or an array.
• Is pure during render: no fetches, no document.title = …, no changing variables outside the function. Compute from props and state; do side effects in handlers or effects.
• Is defined at the top level of a module, never inside another component (gotcha below).

The common convention is one exported component per file, with the file named after it: UserCard.jsx exports UserCard. Small helpers that only that component uses can live in the same file without being exported. You find a component by its file name, a change to one component touches one file in the git history, and Vite's React plugin can only Fast Refresh a file (keep state while you edit) when everything it exports is a component.

The second decision is how to export it. A default export is the module's one unnamed main value; the importer picks any name it likes. A named export has a fixed name that every importer must spell exactly. Mental model: a default export is a parcel left at the door: whoever picks it up can write any label on it. A named export is a parcel with the recipient's name printed on it: get the name wrong and it isn't delivered.

// default export: one per module, imported under any name
export default function Button({ children, ...props }) {
  return <button {...props}>{children}</button>;
}

// named exports: as many as you like, imported by exact name
export function BarChart() {
  return <p>bar chart</p>;
}

export function LineChart() {
  return <p>line chart</p>;
}

import Button from "./Button.jsx";      // any name works...
import Whatever from "./Button.jsx";    // ...this is the same function (Whatever === Button is true)
import { BarChart, LineChart } from "./charts.jsx";
import { BarChart as Chart } from "./charts.jsx"; // renaming a named import is explicit

// format.mjs
export function formatPrice(n) { return `₹${n}`; }
export default function formatDate(d) { return d.toISOString().slice(0, 10); }

// rename.mjs: wrong name for the default export, no error
import formatPrice from "./format.mjs";
console.log(formatPrice(new Date("2026-10-09"))); // 2026-10-09  (it's formatDate!)

// typo.mjs: wrong name for a named export
import { formatPrise } from "./format.mjs";
// Node 26: SyntaxError: The requested module './format.mjs' does not provide an export named 'formatPrise'
// vite build: [MISSING_EXPORT] "formatPrise" is not exported by "format.mjs".

How the two compare in practice:

Tree shaking works with both; the one trap is a default export of an object (export default { formatPrice, formatDate }), which bundlers can't split apart (see the Advanced part). Barrel files (index.js files that re-export a folder, export { default as Button } from "./Button.jsx") give short import paths, but every import from the barrel loads every module it re-exports during development and in tests, and a re-exported module with side effects can stop the bundler dropping it. Keep barrels small, one per feature or package, not one for the whole app.

Many teams use named exports everywhere, and default exports only where a tool requires one: Next.js page.tsx and layout.tsx files, Storybook's story metadata, config files like vite.config.ts, and the target of React.lazy.

React.lazy expects the dynamic import() to resolve to a module with a default export (see Code splitting with React.lazy and Suspense). For a named export, map it:

import { lazy, Suspense } from "react";

// charts.jsx only has named exports: turn the one we want into { default: … }
const LineChart = lazy(() => import("./charts.jsx").then((m) => ({ default: m.LineChart })));

export function Dashboard() {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <LineChart />
    </Suspense>
  );
}

// renders "Loading…", then "line chart"
// without the .then: "Element type is invalid. Received a promise that resolves to: undefined.
//                     Lazy element type must resolve to a class or function."

Colocate a component's other files next to it, in a folder named after it, so moving or deleting the component moves or deletes everything that belongs to it (see Structuring a React project):

src/components/Button/
  Button.jsx           the component (export function Button)
  Button.module.css    its styles
  Button.test.jsx      its tests
  Button.stories.jsx   its Storybook stories
  index.js             export { Button } from "./Button.jsx";  (optional, for short imports)

// utils-object.js: one default export holding both functions
function formatPrice(n) { return "PRICE:" + n; }
function formatDate(d) { return "DATE:" + d; }
export default { formatPrice, formatDate };

// utils-named.js: two named exports
export function formatPrice(n) { return "PRICE:" + n; }
export function formatDate(d) { return "DATE:" + d; }

// entry-object.js: import utils from "./utils-object.js";       utils.formatPrice(5)
// entry-named.js:  import { formatPrice } from "./utils-named.js";  formatPrice(5)

// built output contains "DATE:"?  object: true   named: false   (also true for object with minify on)

Props are the inputs to a component: the attributes you write on the JSX tag, collected into one object and passed as the function's argument. They're how a parent configures a child — what text to show, what data to display, what to do when something is clicked. Any JavaScript value can be a prop: strings, numbers, objects, arrays, functions, and even JSX.

From my notes: props are inputs passed from a parent, they're immutable (the child can't change them), and they're what make a component dynamic. The mental model is function arguments: a component can't reach out and change the arguments it was called with, and when the parent wants a different result, it calls again with different arguments — React re-renders the child with the new props.

export function UserCard({ user, compact, onSelect, badge }) {
  const { name, role, skills } = user;

  return (
    <li className={compact ? "card compact" : "card"} onClick={() => onSelect(user.id)}>
      <strong>{name}</strong>
      {badge}
      {!compact && <span> · {role}</span>}
      {!compact && <small> · {skills.join(", ")}</small>}
    </li>
  );
}

export function Team({ members, onSelect }) {
  return (
    <ul>
      {members.map((member) => (
        <UserCard
          key={member.id}
          user={member}
          compact={members.length > 3}
          onSelect={onSelect}
          badge={member.lead ? <em> lead</em> : null}
        />
      ))}
    </ul>
  );
}

// <Team members={[{ id: 7, name: "Rohit", role: "Engineer", skills: ["React", "Kotlin"], lead: true },
//                 { id: 9, name: "Asha", role: "Designer", skills: ["Figma"] }]} onSelect={fn} />
// → <li class="card"><strong>Rohit</strong><em> lead</em><span> · Engineer</span><small> · React, Kotlin</small></li>
//   <li class="card"><strong>Asha</strong><span> · Designer</span><small> · Figma</small></li>
// clicking "Asha" calls fn(9)

How props are written:

• Strings can use quotes: role="admin". Everything else needs braces: size={48}, active={false}, user={user}, onClick={handleClick}. size="48" gives the string "48"; size={48} the number.
• A bare attribute means true: <Button disabled /> is disabled={true}.
• Spread passes every property of an object as a prop: <UserCard {...member} />. Rest collects the props you didn't name, which is how wrappers forward attributes to the element underneath:

function TextField({ label, ...inputProps }) {
  return (
    <label>
      {label}
      <input {...inputProps} />
    </label>
  );
}

// <TextField label="Email" type="email" placeholder="you@example.com" required />
// → <label>Email<input placeholder="you@example.com" required="" type="email"></label>

Props are read-only: in development React freezes the props object, and assigning to it throws TypeError: Cannot assign to read only property 'text' of object '#<Object>' (see One-way data flow). If a component needs a value that changes over time, that's state, which State vs props compares side by side.

children is a special prop holding whatever you put between a component's opening and closing tags. <Card title="Profile"><p>Rohit</p></Card> calls Card with { title: "Profile", children: <p>Rohit</p> }. It lets a component be a container that doesn't know or care what it contains — like a picture frame, which works the same whatever picture you put in it.

That's the heart of what React calls composition over inheritance. In class-based UI frameworks you specialise a component by subclassing it (class DangerButton extends Button). React doesn't do that: you build specific components by combining generic ones and passing them content and configuration through props and children. From my notes: composition "means it's flexible and generic — it doesn't care what is being passed to it, either through props or children."

My notes had two examples; the first (the children version) was a screenshot that didn't come through, so this is a new one:

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

export function Dashboard() {
  return (
    <>
      <Card title="Profile">
        <p>Rohit Varma</p>
        <button>Edit</button>
      </Card>
      <Card title="Stats">
        <ul>
          <li>Commits: 42</li>
        </ul>
      </Card>
    </>
  );
}

// → <section class="card"><h2>Profile</h2><div class="card-body"><p>Rohit Varma</p><button>Edit</button></div></section>
//   <section class="card"><h2>Stats</h2><div class="card-body"><ul><li>Commits: 42</li></ul></div></section>

When a component has several places to fill, pass each one as its own prop. This is the second example from my notes (written in TypeScript there with React.FC<ModalProps>; here as JSX):

export function Modal({ header, body, footer }) {
  return (
    <div className="modal" role="dialog">
      <div className="modal-header">{header}</div>
      <div className="modal-body">{body}</div>
      <div className="modal-footer">{footer}</div>
    </div>
  );
}

export function App() {
  return (
    <Modal
      header={<h2>Modal Title</h2>}
      body={<p>This is the modal content</p>}
      footer={<button>Close</button>}
    />
  );
}

What children can be — the test logs typeof for each case:

function Dialog({ title, tone = "neutral", children }) {
  return (
    <div role="alertdialog" className={`dialog dialog-${tone}`}>
      <h2>{title}</h2>
      {children}
    </div>
  );
}

export function DeleteDialog({ itemName, onConfirm }) {
  return (
    <Dialog title={`Delete ${itemName}?`} tone="danger">
      <p>This can't be undone.</p>
      <button onClick={onConfirm}>Delete</button>
    </Dialog>
  );
}

<NumberedList><span>Plan</span><span>Build</span>{false}<span>Ship</span></NumberedList>
// Children.map gives: <li>1. Plan</li><li>2. Build</li><li>3. </li><li>4. Ship</li>

<NumberedList><Steps /></NumberedList>   // Steps returns <><span>Plan</span><span>Build</span></>
// Children.map gives: <li>1. <span>Plan</span><span>Build</span></li>

Optional props need fallback values: a button's size should be "md" unless someone says otherwise. Today you write them as JavaScript default parameters in the destructuring pattern. Older code set a static defaultProps object on the component instead. In React 19 that old way no longer works for function components — it's silently ignored — so it's worth recognising.

function Heading({ text = "Hello, world!", level = 2 }) {
  const Tag = `h${level}`;
  return <Tag>{text}</Tag>;
}

<Heading />                    // <h2>Hello, world!</h2>
<Heading text="Hi" level={1} /> // <h1>Hi</h1>
<Heading text={undefined} />   // <h2>Hello, world!</h2>
<Heading text={null} />        // <h2></h2>   ← null is a value, so no default

Old and new:

// React 18 and earlier — function components
function OldHeading({ text }) {
  return <h2>{text}</h2>;
}
OldHeading.defaultProps = { text: "Hello, world!" };

// React 19.3: <OldHeading /> renders <h2></h2> — the default is silently ignored, no warning

// Class components still support defaultProps in React 19
class ClassHeading extends Component {
  static defaultProps = { text: "Hello from a class" };
  render() {
    return <h2>{this.props.text}</h2>;
  }
}
// <ClassHeading /> → <h2>Hello from a class</h2>

PropTypes describe what props a component expects — "name is a required string, age is a number" — and, in older React, React checked them at runtime in development and logged a warning when a prop had the wrong type. They come from the separate prop-types package. From my notes: "If you do TypeScript you don't need these, but for projects still on JavaScript, it's good to have."

That was right in 2024; in React 19 it changed. PropTypes were deprecated back in React 15.5 (2017), and React 19 removed the checking entirely: React no longer reads propTypes at all. They're silently ignored. So today "PropTypes or TypeScript?" is really "TypeScript (or JSDoc types), or no checking".

My notes' example:

import PropTypes from "prop-types";

function MyComponent({ name, age, isActive }) {
  return (
    <div>
      <h1>{name}</h1>
      <p>Age: {age}</p>
      <p>Status: {isActive ? "Active" : "Inactive"}</p>
    </div>
  );
}

MyComponent.propTypes = {
  name: PropTypes.string.isRequired, // name must be a string and is required
  age: PropTypes.number,             // age should be a number
  isActive: PropTypes.bool,          // isActive should be a boolean
};

// <MyComponent age="thirty" />
// React 18 and earlier (dev): two warnings in the console
//   Warning: Failed prop type: The prop `name` is marked as required in `MyComponent`, but its value is `undefined`.
//   Warning: Failed prop type: Invalid prop `age` of type `string` supplied to `MyComponent`, expected `number`.
// React 19.3: renders <h1></h1><p>Age: thirty</p>… and logs nothing

The TypeScript version catches the same mistakes at compile time, in your editor, before anything runs:

type ProfileProps = {
  name: string;
  age?: number;
  isActive?: boolean;
};

export function Profile({ name, age, isActive = false }: ProfileProps) {
  return (
    <div>
      <h1>{name}</h1>
      {age !== undefined && <p>Age: {age}</p>}
      <p>Status: {isActive ? "Active" : "Inactive"}</p>
    </div>
  );
}

<Profile age={30} />;                // ❌ TS2741: Property 'name' is missing in type '{ age: number; }' but required in type 'ProfileProps'.
<Profile name="Rohit" age="thirty" />; // ❌ TS2322: Type 'string' is not assignable to type 'number'.

Where runtime checking still matters: data the compiler can't see, such as API responses, form input, localStorage, URL params. TypeScript trusts whatever type you claim for a fetch result. For that, validate at the boundary with a schema library like Zod (see Schema validation with Zod) — that's the modern replacement for the runtime half of PropTypes.

Badge.propTypes = {
  size: PropTypes.oneOf(["sm", "md", "lg"]),
  user: PropTypes.shape({ id: PropTypes.number.isRequired, name: PropTypes.string }),
  tags: PropTypes.arrayOf(PropTypes.string),
  onClick: PropTypes.func.isRequired,
  children: PropTypes.node,
};

// checkPropTypes(…, { size: "xl", user: { name: "Rohit" }, tags: ["a", 1] }, …) logs:
// Warning: Failed prop type: Invalid prop `size` of value `xl` supplied to `Badge`, expected one of ["sm","md","lg"].
// Warning: Failed prop type: The prop `user.id` is marked as required in `Badge`, but its value is `undefined`.
// Warning: Failed prop type: Invalid prop `tags[1]` of type `number` supplied to `Badge`, expected `string`.
// Warning: Failed prop type: The prop `onClick` is marked as required in `Badge`, but its value is `undefined`.

A component must return one root, but sometimes you want to return several siblings without adding a wrapper element. A fragment groups children for React without creating any DOM node. From my notes: fragments group multiple elements without adding extra nodes to the DOM, using React.Fragment or the shorthand <>…</>, and they help reduce unnecessary DOM nodes.

The mental model: a fragment is a paper clip, not an envelope. It holds the pages together while you hand them over, and then disappears — the receiver gets the pages, not a container.

function Columns() {
  return (
    <>
      <td>Rohit</td>
      <td>Engineer</td>
    </>
  );
}

export function Table() {
  return (
    <table>
      <tbody>
        <tr>
          <Columns />
        </tr>
      </tbody>
    </table>
  );
}

// → <table><tbody><tr><td>Rohit</td><td>Engineer</td></tr></tbody></table>

The short syntax <>…</> can't take attributes. When you render a list of groups, each group needs a key, so use the long form:

import { Fragment } from "react";

export function Glossary({ terms }) {
  return (
    <dl>
      {terms.map((term) => (
        <Fragment key={term.id}>
          <dt>{term.word}</dt>
          <dd>{term.meaning}</dd>
        </Fragment>
      ))}
    </dl>
  );
}

// → <dl><dt>JSX</dt><dd>Syntax for elements</dd><dt>Fiber</dt><dd>The reconciler</dd></dl>

When to use them: returning siblings from a component, keeping CSS layouts that depend on direct children (flexbox, grid, :first-child) intact, and inside elements with strict content rules (table, tr, ul, dl, select). Don't reach for a div just to satisfy the one-root rule.

function Group() {
  const ref = useRef(null);
  useEffect(() => {
    ref.current.addEventListener("click", (e) => console.log(e.target.textContent));
    ref.current.focus(); // focuses the first focusable child
  }, []);
  return (
    <Fragment ref={ref}>
      <button>One</button>
      <button>Two</button>
    </Fragment>
  );
}
// ref.current.constructor.name → "FragmentInstance"
// clicking each button logs "One", "Two"; after focus(), document.activeElement is "One"

Components often need to show different things depending on data: a spinner while loading, an error message, an empty state, a badge only when there are unread items. Since a component is just a function returning JSX, conditional rendering is ordinary JavaScript: if statements before the return, and expressions (? :, &&, ??) inside the JSX. There's no special v-if or *ngIf syntax.

The mental model: JSX is a value, so choosing what to render is choosing which value to return — like choosing which string to return from a function.

export function Inbox({ status, messages, user }) {
  if (status === "loading") return <p>Loading…</p>; // early return
  if (status === "error") return null;               // render nothing

  return (
    <section>
      <h2>{user ? `Hi, ${user.name}` : "Hi, guest"}</h2>
      {messages.length > 0 && <span className="badge">{messages.length} new</span>}
      {messages.length === 0 ? <p>All caught up</p> : <ul>{messages.map((m) => <li key={m.id}>{m.subject}</li>)}</ul>}
    </section>
  );
}

// status="loading"             → <p>Loading…</p>
// status="error"               → (nothing)
// ready, no messages, no user  → <section><h2>Hi, guest</h2><p>All caught up</p></section>
// ready, 2 messages, Rohit     → <section><h2>Hi, Rohit</h2><span class="badge">2 new</span><ul><li>Offer</li><li>Interview</li></ul></section>

For more than two cases, a lookup object beats nested ternaries:

const icons = { success: "✅", warning: "⚠️", error: "⛔" };

export function StatusIcon({ kind }) {
  return <span role="img" aria-label={kind}>{icons[kind] ?? "ℹ️"}</span>;
}
// kind="warning" → ⚠️     kind="other" → ℹ️

To render a list, you turn an array of data into an array of elements, almost always with .map(). React renders arrays as siblings. Each item needs a key: a string or number that identifies that item among its siblings and stays the same across renders.

From my notes: React uses keys to identify which items in a list have changed, been added or been removed; keys help reconciliation, and incorrect keys lead to bugs. The mental model: keys are name tags at a party. Without them, React can only say "the first person, the second person…". If the first person leaves, everyone shifts up a place, and React thinks the second person is now the first — and gives them the first person's coat. With name tags, React knows exactly who left.

My notes' example uses the index as the key:

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo, index) => (
        <li key={index}>{todo}</li> // ⚠️ fine only if the list never changes order
      ))}
    </ul>
  );
}

For plain text like that you won't see a bug, because React just updates each li's text. The bug appears as soon as a list item has state or DOM state of its own — an input, a checkbox, an open/closed toggle. Here's the bug made visible:

function TodoRow({ todo, onRemove }) {
  return (
    <li>
      {todo.text}
      <input aria-label={`note for ${todo.text}`} placeholder="note" />
      <button onClick={() => onRemove(todo.id)}>Remove {todo.text}</button>
    </li>
  );
}

export function TodoList({ useIndexAsKey }) {
  const [todos, setTodos] = useState([
    { id: "t1", text: "Write tests" },
    { id: "t2", text: "Fix bug" },
    { id: "t3", text: "Deploy" },
  ]);
  const remove = (id) => setTodos(todos.filter((t) => t.id !== id));

  return (
    <ul>
      {todos.map((todo, index) => (
        <TodoRow key={useIndexAsKey ? index : todo.id} todo={todo} onRemove={remove} />
      ))}
    </ul>
  );
}

// type "mine" into the note for "Write tests", then remove "Write tests":
// key={index}   → ["Fix bug=\"mine\"", "Deploy=\"\""]   ❌ the note jumped to the wrong row
// key={todo.id} → ["Fix bug=\"\"",     "Deploy=\"\""]   ✅

Rules for keys:

• Unique among siblings (not globally) and stable: the same item gets the same key every render.
• Use an id from the data: a database id, a slug, a UUID created when the item was created.
• Index is acceptable only when the list is static: never reordered, filtered, or inserted into, and items have no state.
• Never key={Math.random()} or a fresh crypto.randomUUID() during render: every render gets new keys, so React unmounts and remounts every item each time (the test confirms the first <li> is a different DOM node after a re-render), destroying state and wasting work.
• The key goes on the outermost element returned from map (the TodoRow, not the li inside it).

The warnings React 19.3 prints for the two common mistakes:

• No key: "Each child in a list should have a unique "key" prop. Check the render method of List. See https://react.dev/link/warning-keys for more information."
• Duplicate keys: "Encountered two children with the same key, a. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version."

A reusable component is one other people can drop into situations you didn't plan for without editing its code. My notes list the principles for reusable components (from the "creating reusable frontend components (SDKs)" section):

• Separation of concerns: each component should do one thing well. Don't mix data fetching and UI rendering in the same component.
• Props-driven design: make components customisable through props, so they adapt to different use cases without changes to their internals.
• State management: keep components as stateless as possible. If state is required, let the parent control it, or lift it up.

The mental model: a reusable component is like a power socket — a small, stable, documented interface (its props) that anything can plug into, with the wiring hidden behind the wall. The fewer assumptions it makes about who plugs in, the more places it works.

My notes had a "reusable button component" heading whose example was a screenshot that didn't come through, so here's one written from scratch:

export function Button({
  variant = "primary",
  size = "md",
  loading = false,
  type = "button",
  className = "",
  disabled,
  children,
  ...rest
}) {
  const classes = ["btn", `btn-${variant}`, `btn-${size}`, className].filter(Boolean).join(" ");

  return (
    <button
      type={type}
      className={classes}
      disabled={disabled || loading}
      aria-busy={loading || undefined}
      {...rest}
    >
      {loading ? "Saving…" : children}
    </button>
  );
}

// <Button onClick={save}>Save</Button>
// → <button type="button" class="btn btn-primary btn-md">Save</button>
// <Button variant="danger" size="sm" className="ml-2" aria-label="Delete item">🗑</Button>
// → <button type="button" class="btn btn-danger btn-sm ml-2" aria-label="Delete item">🗑</button>
// <Button loading>Save</Button>
// → <button type="button" class="btn btn-primary btn-md" disabled="" aria-busy="true">Saving…</button>

Composing small reusable pieces into a bigger one — this is the Form example from my notes ("Form component composed of smaller components"), made runnable:

import { useId } from "react";
import { Button } from "./Button.jsx";

export function Input({ label, error, ...inputProps }) {
  const id = useId();
  const errorId = `${id}-error`;
  return (
    <div className="field">
      <label htmlFor={id}>{label}</label>
      <input id={id} aria-invalid={error ? true : undefined} aria-describedby={error ? errorId : undefined} {...inputProps} />
      {error && <p id={errorId} className="field-error">{error}</p>}
    </div>
  );
}

export function LoginForm({ onSubmit, saving, error }) {
  const handleSubmit = (event) => {
    event.preventDefault();
    const data = new FormData(event.currentTarget);
    onSubmit({ username: data.get("username"), password: data.get("password") });
  };

  return (
    <form onSubmit={handleSubmit}>
      <Input label="Username" name="username" />
      <Input label="Password" name="password" type="password" error={error} />
      <Button type="submit" loading={saving}>Submit</Button>
    </form>
  );
}

A checklist for a component other people will use:

• Few required props, sensible defaults for everything else.
• Forward the rest (...rest) to the main DOM element, and accept className (and ref in React 19) so callers can integrate it.
• Use children for content rather than a dozen text props.
• Don't fetch data inside UI components; take data and callbacks as props, and keep fetching in a page component or a hook.
• Support controlled and uncontrolled use for anything with a value (below).
• Accessible by default: real <button>s, labels linked to inputs, aria-* handled inside.
• Name events after what happened (onSelect, onClose), not how (handleClick).

import { useState } from "react";

// Works controlled (pass `on` + `onChange`) or uncontrolled (pass `defaultOn`, or nothing)
export function Toggle({ on, defaultOn = false, onChange, label }) {
  const [internalOn, setInternalOn] = useState(defaultOn);
  const isControlled = on !== undefined;
  const value = isControlled ? on : internalOn;

  const flip = () => {
    if (!isControlled) setInternalOn(!value);
    onChange?.(!value);
  };

  return (
    <button role="switch" aria-checked={value} onClick={flip}>
      {label}: {value ? "On" : "Off"}
    </button>
  );
}

// <Toggle label="Wifi" />                         click → "Wifi: On"        (uncontrolled)
// <Toggle label="Dark mode" on={dark} onChange={setDark} />  dark=true, click → "Dark mode: Off"
// <Toggle label="Locked" on={false} onChange={log} />  click → still "Locked: Off", log(true) called

When a set of reusable components becomes a shared package for several apps — packaging, tree shaking, versioning, theming and documentation — see Building a reusable component library.