React

# Framework path — what react.dev itself recommends starting from
npx create-next-app@latest my-app --typescript

cd my-app
npm run dev

# Plain-Vite path — no framework, just React + a build tool. What every other
# starter on this page assumes, since this cheat sheet covers React itself,
# not a specific framework's routing/data-fetching APIs.
npm create vite@latest my-app -- --template react-ts

cd my-app
npm install
npm run dev

# Build for production, then preview that build locally
npm run build
npm run preview

A couple of commonly-needed extras on top of the plain-Vite path:

# Client-side routing (framework-free — Next.js has its own router built in)
npm install react-router-dom

# Fetching/caching server state (an alternative to hand-rolled useFetch hooks)
npm install @tanstack/react-query

If you’re building a real product, start with the framework path — react.dev is explicit that it’s the recommended default now, since it solves routing, data fetching, and server rendering you’d otherwise have to wire up by hand. The Vite path is what this page’s other starters assume, since they’re about React itself rather than any one framework’s conventions.

interface CardProps {
  title: string;
  onSelect?: () => void;
}

function Card({ title, onSelect }: CardProps) {
  return (
    <div className="card" onClick={onSelect}>
      <h3>{title}</h3>
    </div>
  );
}

export default Card;

Copy this, rename Card/CardProps, and fill in the markup — this is the skeleton for the large majority of components that just take some data and render it, with no internal state of their own.

interface PanelProps {
  title: string;
  children: React.ReactNode;
}

function Panel({ title, children }: PanelProps) {
  return (
    <section className="panel">
      <h3>{title}</h3>
      <div className="panel-body">{children}</div>
    </section>
  );
}

export default Panel;

The difference from a plain component starter is just the children prop — typed as React.ReactNode rather than a specific value — which lets the caller pass any markup through instead of a fixed set of props.

import { useState } from 'react';

interface CounterProps {
  initialCount?: number;
}

function Counter({ initialCount = 0 }: CounterProps) {
  const [count, setCount] = useState(initialCount);

  return (
    <button onClick={() => setCount((c) => c + 1)}>
      Count: {count}
    </button>
  );
}

export default Counter;

This is the same shape as the plain component starter with one useState call added — copy it as the starting point any time a component needs to remember something between renders that isn’t passed in from a parent.

import { forwardRef } from 'react';

interface TextInputProps {
  label: string;
}

const TextInput = forwardRef<HTMLInputElement, TextInputProps>(
  ({ label }, ref) => (
    <label>
      {label}
      <input ref={ref} />
    </label>
  )
);

TextInput.displayName = 'TextInput';

export default TextInput;

A parent can now do <TextInput ref={inputRef} label="Name" /> and call inputRef.current.focus() — without forwardRef, the ref prop would be silently dropped rather than reaching the underlying <input>.

import { useState, useCallback } from 'react';

function useToggle(initial = false) {
  const [value, setValue] = useState(initial);

  const toggle = useCallback(() => setValue((v) => !v), []);

  return [value, toggle] as const;
}

export default useToggle;

Used as const [isOpen, toggleOpen] = useToggle(); — copy this shape for any bit of stateful logic (a toggle, a fetch, a subscription) that more than one component needs, and rename useToggle/value/toggle to fit.

import { createContext, useContext, useState, type ReactNode } from 'react';

interface ThemeContextValue {
  theme: 'light' | 'dark';
  toggleTheme: () => void;
}

const ThemeContext = createContext<ThemeContextValue | undefined>(undefined);

export function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<'light' | 'dark'>('light');
  const toggleTheme = () => setTheme((t) => (t === 'light' ? 'dark' : 'light'));

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

export function useTheme() {
  const ctx = useContext(ThemeContext);
  if (!ctx) throw new Error('useTheme must be used within a ThemeProvider');
  return ctx;
}

Wrap the subtree once in <ThemeProvider>, then any component inside it just calls const { theme, toggleTheme } = useTheme(); — no prop drilling, and the guard clause catches a missing provider immediately instead of a confusing undefined further down the tree.

import { useState, useEffect } from 'react';

function useFetch<T>(url: string) {
  const [data, setData] = useState<T | null>(null);
  const [error, setError] = useState<Error | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const controller = new AbortController();
    setLoading(true);

    fetch(url, { signal: controller.signal })
      .then((res) => res.json())
      .then((json: T) => setData(json))
      .catch((err) => {
        if (err.name !== 'AbortError') setError(err);
      })
      .finally(() => setLoading(false));

    return () => controller.abort();
  }, [url]);

  return { data, error, loading };
}

export default useFetch;

Used as const { data, error, loading } = useFetch<User[]>('/api/users'); — copy this shape for any request, and swap fetch for a project’s own API client if it has one; the state shape and cleanup stay the same.

import { Component, type ReactNode } from 'react';

interface Props {
  fallback: ReactNode;
  children: ReactNode;
}

interface State {
  hasError: boolean;
}

class ErrorBoundary extends Component<Props, State> {
  state: State = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error: Error) {
    console.error('ErrorBoundary caught:', error);
  }

  render() {
    return this.state.hasError ? this.props.fallback : this.props.children;
  }
}

export default ErrorBoundary;

Used as <ErrorBoundary fallback={<p>Something went wrong.</p>}>...</ErrorBoundary> around a specific widget or route — this is still a class component because React has no hook equivalent for catching render errors in a subtree.

import { createContext, useContext, useState, type ReactNode } from 'react';

const TabsContext = createContext<{ active: string; setActive: (id: string) => void } | undefined>(undefined);

function Tabs({ defaultTab, children }: { defaultTab: string; children: ReactNode }) {
  const [active, setActive] = useState(defaultTab);
  return <TabsContext.Provider value={{ active, setActive }}>{children}</TabsContext.Provider>;
}

function Tab({ id, children }: { id: string; children: ReactNode }) {
  const ctx = useContext(TabsContext);
  if (!ctx) throw new Error('Tabs.Tab must be used within <Tabs>');
  return (
    <button aria-pressed={ctx.active === id} onClick={() => ctx.setActive(id)}>
      {children}
    </button>
  );
}

Tabs.Tab = Tab;
export default Tabs;

Used as <Tabs defaultTab="a"><Tabs.Tab id="a">First</Tabs.Tab><Tabs.Tab id="b">Second</Tabs.Tab></Tabs> — the same context-plus-hook idea as the standalone context starter, just scoped to one component family instead of a whole subtree.

import { lazy, Suspense } from 'react';

const ChartPanel = lazy(() => import('./ChartPanel'));

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

export default Dashboard;

ChartPanel’s code is not downloaded until Dashboard actually renders it — reach for this for anything large and not needed on first paint (a chart library, a modal’s contents, a rarely-visited settings panel).

function ProductCard({ product }) {
  return (
    <>
      <h3>{product.name}</h3>
      <p>{product.inStock ? 'In stock' : 'Out of stock'}</p>
      <ul>
        {product.tags.map((tag) => (
          <li key={tag}>{tag}</li>
        ))}
      </ul>
    </>
  );
}

Under the hood, JSX compiles to nested calls that build a plain JavaScript object describing the UI — the curly braces are how any JS expression gets embedded into that description, not a templating mini-language of their own.

The key on each <li> is not styling or an attribute for the browser; it is a hint React uses to match array items between one render and the next, so it can tell an insertion or reorder apart from every item changing.

function OrderPage({ user }) {
  return <OrderSummary user={user} />;
}

function OrderSummary({ user }) {
  return <UserBadge user={user} />;
}

function UserBadge({ user }) {
  return <span>{user.name}</span>;
}

Only UserBadge actually reads user, but OrderPage and OrderSummary both have to accept and forward it just to pass it along — that’s prop drilling. It’s harmless for one or two hops, but once a value has to cross four or five components untouched, it’s usually the signal to reach for context or restructure the component tree instead.

function Counter() {
  const [count, setCount] = useState(0);

  function handleIncrement() {
    setCount((prev) => prev + 1);
  }

  return <button onClick={handleIncrement}>Count: {count}</button>;
}

Passing a function to setCount instead of a plain value matters whenever the next value depends on the previous one — it always receives the latest state, even if several updates are queued before React re-renders.

Calling the setter never changes count immediately in the current render; it tells React to schedule a new render where count will hold the updated value, which is why reading count again right after calling setCount still shows the old number.

For a ready-to-copy component built on this pattern, see the Component with Local State Starter in Starter Templates.

function ShippingForm({ expedited }) {
  // Wrong: this hook call is skipped entirely on some renders
  if (expedited) {
    const [rushFee, setRushFee] = useState(25);
  }

  // Right: always call the hook, branch on the value instead
  const [rushFee, setRushFee] = useState(expedited ? 25 : 0);

  return <p>Rush fee: ${rushFee}</p>;
}

React has no idea a hook is named rushFee — it only knows it was the second useState call during this render. If a condition makes that call happen on some renders and not others, every hook after it shifts position and silently reads or writes the wrong slot of state.

That’s the entire reasoning behind the rule: call hooks only at the top level of a function component or another hook, in the same order, on every single render, no matter which branch the render takes.

Writing a new hook of your own? See the Custom Hook Starter and Data-Fetching Hook Starter in Starter Templates for a ready-to-copy shape.

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    const controller = new AbortController();
    fetchResults(query, controller.signal).then(setResults);
    return () => controller.abort();
  }, [query]);

  return <ResultsList items={results} />;
}

The effect only re-runs when query changes, since that’s the single value listed in its dependency array — an empty array would mean “run once on mount,” and omitting the array entirely would mean “run after every render.”

The cleanup function returned here cancels the in-flight request before the next effect run starts, which is what stops a slow response to an earlier query from overwriting the results of a newer one.

This exact fetch-cancel-cleanup shape is common enough to be worth its own starter — see the Data-Fetching Hook Starter in Starter Templates for a version wrapped up as a reusable hook.

function SearchInput() {
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  return <input ref={inputRef} type="text" placeholder="Search..." />;
}

inputRef.current starts out null and is filled in by React with the actual DOM node once the <input> mounts, which is why reading it is only safe inside an effect or event handler, never during render itself.

Refs exist for the cases React’s declarative model doesn’t cover directly — focusing an element, measuring its size, or triggering an imperative method on a video player — anywhere the DOM node itself needs to be touched rather than described.

If a parent needs that same ref to reach a child’s DOM node, see the forwardRef Component Starter in Starter Templates.

const ThemeContext = createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

function Toolbar() {
  const theme = useContext(ThemeContext);
  return <div className={`toolbar toolbar--${theme}`} />;
}

Toolbar reads theme without App ever passing it a prop, and without any component in between needing to know the value exists at all — that’s what makes context a fix for prop drilling on values many components need, like theme, locale, or the current user.

It isn’t free, though: every component reading a given context re-renders whenever that context’s value changes, so it fits widely-shared, slowly changing values better than anything that updates on every keystroke.

For the fuller pattern — context, provider component, and a guarded hook all together — see the Context + Provider + Hook Starter in Starter Templates.

function ProductList({ products, onSelect }) {
  const sorted = useMemo(
    () => [...products].sort((a, b) => a.price - b.price),
    [products]
  );

  const handleSelect = useCallback((id) => onSelect(id), [onSelect]);

  return sorted.map((p) => (
    <ProductRow key={p.id} product={p} onSelect={handleSelect} />
  ));
}

sorted is only recomputed when products changes, instead of re-sorting on every render of ProductList — including renders triggered by something else entirely, like a sibling’s state changing.

useCallback does the same job for a function reference rather than a value: handleSelect stays the same function across renders as long as onSelect hasn’t changed, which matters specifically because ProductRow is wrapped in React.memo and would otherwise re-render on every pass.