React Hooks and TypeScript: A Practical Guide

Picture this: you have just inherited a React codebase with 47 class components, each carrying its own Props interface, State interface, and a constructor that copies half the props into state. You open the first file and find yourself staring at 30 lines of type declarations before a single line of business logic. The previous developer meant well, but the result is a codebase where TypeScript creates more friction than safety.

This was the daily reality for thousands of React teams before hooks arrived. TypeScript and React were individually excellent, but together they produced a kind of bureaucratic overhead that made developers question whether static typing was worth the cost. Hooks changed that equation entirely.

At Boundev, our React development teams migrated dozens of client codebases from class components to hooks-based architectures. The pattern we saw was consistent: type declarations dropped by 40–60%, bugs caught at compile time increased, and developer velocity improved noticeably within the first sprint. In this guide, we will walk you through exactly how React Hooks and TypeScript work together, with practical code examples you can apply to your own projects today.

Why Class Components Made TypeScript Painful

Before hooks, React had two component flavors: class components that could manage state, and functional components that were purely defined by their props. If you needed state, you needed a class. And if you were using TypeScript, that class needed two separate generic type parameters — one for props, one for state — even when many of their keys were identical.

Consider a simple quotation management app. You have a domain object, a state interface, and a props interface. All three share overlapping fields, but TypeScript forces you to declare each one explicitly.

interface Quotation {
  id: number;
  title: string;
  lines: QuotationLine[];
  price: number;
}

interface QuotationState {
  readonly quotation: Quotation;
  signed: boolean;
}

interface QuotationProps {
  quotation: Quotation;
}

class QuotationPage extends Component<QuotationProps, QuotationState> {
  // ... business logic buried under type ceremony
}

Three interfaces for one component. And the moment your requirements shift — say, the component now fetches the quotation by ID from a server instead of receiving it via props — you need to restructure QuotationProps to exclude the id field. Suddenly, you are manually copying every attribute except one into a new interface. It feels like writing Java DTOs all over again.

This duplication was not just annoying. It was genuinely dangerous. When interfaces diverge from the domain model, you lose the very guarantee that TypeScript is supposed to provide. Developers start using any to bypass the noise, and type safety quietly erodes.

How Hooks Eliminate the Type Ceremony

Here is the turning point. With hooks, you split the monolithic QuotationState interface into individual pieces of state, each managed by its own useState call. TypeScript infers the types automatically from default values, so you write zero additional interfaces for local state.

interface QuotationProps {
  quotation: Quotation;
}

function QuotationPage({ quotation }: QuotationProps) {
  const [currentQuotation, setQuotation] = useState(quotation);
  const [signed, setSigned] = useState(false);
  // TypeScript knows: currentQuotation is Quotation, signed is boolean
}

Gone is the QuotationState interface. Gone is the class declaration with its two generic parameters. The useState hook infers that signed is a boolean from the default value false, and currentQuotation is a Quotation from the prop. You get identical type safety with dramatically less code.

You can also express the component as a typed functional component using React's FC type, which makes the return type and props generic explicit in one clean declaration:

const QuotationPage: FC<QuotationProps> = ({ quotation }) => {
  const [currentQuotation, setQuotation] = useState(quotation);
  const [signed, setSigned] = useState(false);
  // clean, readable, fully typed
};

This is the shift that makes TypeScript go from "tolerable overhead" to "genuinely pleasant." You no longer fight the type system — you work with it. And when you add side effects, the experience only gets better.

Side Effects Made Type-Safe with useEffect

In class components, side effects were scattered across componentDidMount, componentDidUpdate, and componentWillUnmount. With hooks, the useEffect hook consolidates all three lifecycle methods into a single declarative API. And because hooks are just function calls, TypeScript can validate their usage without any special configuration.

function QuotationSignature({ quotation }: QuotationProps) {
  const [signed, setSigned] = useState(quotation.signed);

  useEffect(() => {
    fetchPost(`quotation/${quotation.number}/sign`);
  }, [signed]); // effect fires only when signed changes

  return (
    <>
      <input
        type="checkbox"
        checked={signed}
        onChange={() => setSigned(!signed)}
      />
      Signature
    </>
  );
}

The dependency array [signed] tells React to re-run the effect only when signed changes. TypeScript validates that signed exists and is the correct type. If you accidentally pass a string where a boolean is expected, the compiler catches it instantly — not your QA team three sprints later.

Utility Types That Change Everything

Here is where TypeScript truly shines with hooks. TypeScript provides a set of utility types that eliminate the repetitive interface declarations that plagued class components. Three utility types in particular are essential for React development:

Instead of manually creating a new interface that mirrors your domain object minus the id field, you write a single line:

// Instead of manually copying every field minus id:
type QuotationProps = Omit<Quotation, 'id'>;

// Or pick only what a specific editor needs:
type QuoteEditFormProps = Pick<Quotation, 'id' | 'title'>;

// Even inline for small components:
function QuotationNameEditor(
  { id, title }: Pick<Quotation, 'id' | 'title'>
) {
  // fully typed, zero boilerplate
}

These utility types do not exist in most statically typed languages like Java or C#. They are unique to TypeScript and tailor-made for frontend development where component props are constantly shifting subsets of domain models. Combined with hooks, they make your React codebase both safer and dramatically more concise.

Type-Safe State Machines with useReducer

When your component state grows beyond two or three useState calls, the useReducer hook becomes a better fit. And this is where TypeScript delivers its most powerful advantage: compile-time validation of every action dispatched against every state transition.

interface Place {
  city: string;
  country: string;
}

type PlaceAction =
  | { type: 'city'; payload: string }
  | { type: 'country'; payload: string };

const initialState: Place = {
  city: 'Rosebud',
  country: 'USA',
};

function reducer(state: Place, action: PlaceAction): Partial<Place> {
  switch (action.type) {
    case 'city':
      return { city: action.payload };
    case 'country':
      return { country: action.payload };
  }
}

function PlaceForm() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <form>
      <input
        type="text"
        name="city"
        value={state.city}
        onChange={(e) =>
          dispatch({ type: 'city', payload: e.target.value })
        }
      />
      <input
        type="text"
        name="country"
        value={state.country}
        onChange={(e) =>
          dispatch({ type: 'country', payload: e.target.value })
        }
      />
    </form>
  );
}

Notice the PlaceAction discriminated union type. If you try to dispatch { type: 'zipcode', payload: '12345' }, TypeScript flags it immediately — 'zipcode' does not exist in the union. This is compile-time state machine validation, the kind of safety that prevents entire categories of runtime bugs from ever reaching your users.

The reducer function naturally extracts outside the component, making it trivially testable. You can unit test every state transition in isolation, without rendering a single React component. This separation of concerns is one of the most underappreciated benefits of the hooks architecture.

Avoiding the Covariance Trap

TypeScript's type system is powerful, but it is not infallible. One subtle pitfall that catches even experienced developers involves structural typing and generics. Consider this scenario:

interface Animal {}
interface Cat extends Animal {
  meow: () => string;
}

const duck = { age: 7 };
const felix = { age: 12, meow: () => "Meow" };

function MyApp() {
  const [cats, setCats] = useState<Cat[]>([felix]);
  // Danger: listOfCats assigned to Animal[] type
  const [animals, setAnimals] = useState<Animal[]>([felix]);
  const [animal, setAnimal] = useState(duck);

  return (
    <div onClick={() => {
      animals.unshift(animal); // duck sneaks into Cat array!
      setAnimals([...animals]);
    }}>
      The first cat says {cats[0].meow()}
    </div>
  );
}

TypeScript uses a bivariant approach for generics — simpler than Java's covariance/contravariance model, but it means you can accidentally assign a Cat[] to an Animal[] and then insert a duck into what should be a list of cats. The compiler will not stop you.

How Boundev Solves This for You

Everything we have covered in this blog — eliminating type boilerplate, building type-safe state machines, and avoiding subtle TypeScript pitfalls — is exactly what our React engineering teams handle every day. Here is how we approach it for our clients.

FAQ