Site icon Next.js & React.js Revolution | Your Daily Web Dev Insight

TypeScript with React Tutorial How to Build Robust Modern Apps

admin

Welcome to our deep-dive on mastering TypeScript with React. This guide is designed to get you building robust, type-safe applications from the ground up. We'll walk through everything from setting up your first project in React and Next.js to correctly typing components, hooks, and even complex state, so you can ship code with confidence.

Why TypeScript Is Non-Negotiable for React Developers in 2026

Let's cut right to it. If you're a React developer today, learning TypeScript isn't just a good idea—it's a core competency. This isn't about jumping on a trend; it's about staying relevant and employable in an ecosystem that has clearly chosen its path.

The industry has spoken. Major frameworks like Next.js now default to TypeScript for new projects. That small detail tells a huge story: modern development roles now expect, and often require, proficiency with it. It's no longer a "nice-to-have" on a resume.

Catching Bugs Before They Happen

The most immediate win with TypeScript is simple: it catches a whole class of errors before your code ever runs. Think about all the times a cannot read property of undefined error has derailed your afternoon. TypeScript's static analysis acts as a safety net, flagging issues with incorrect data types, null values, and mismatched component props right in your editor.

This has a massive impact on team projects. In a JavaScript codebase, you often have to dig through files just to figure out what props a component needs. With TypeScript, that contract is crystal clear and self-documenting. It makes onboarding new developers and integrating features so much smoother.

The growth of TypeScript has been nothing short of explosive. Stack Overflow's 2025 survey showed its adoption hit 48.8% among professional developers—a massive leap from just 12% in 2017.

Building a Foundation for Scalable Apps

The benefits go far beyond just preventing bugs. As your React application grows, so does its complexity. TypeScript provides the guardrails needed to manage that scale without turning your codebase into a tangled mess.

Here's what that looks like in practice:

To help illustrate the practical differences, here's a quick comparison of how TypeScript and JavaScript stack up in a modern React project.

TypeScript vs JavaScript for React Development in 2026

Feature Plain JavaScript TypeScript
Type Safety Dynamic typing; errors found at runtime. Static typing; errors caught during development.
Tooling & IDE Support Basic autocompletion and error checking. Advanced IntelliSense, refactoring, and navigation.
Code Readability Relies on JSDoc and naming conventions. Types provide explicit, self-documenting code.
Team Onboarding Steeper learning curve for new developers. Faster onboarding due to clear data contracts.
Scalability Can become difficult to maintain in large projects. Designed for building and maintaining large-scale apps.
Ecosystem Default No longer the default for many modern tools. The default for frameworks like Next.js.

Ultimately, the choice is clear. TypeScript provides the structure and safety that modern, complex web applications demand.

Investing your time in this typescript with react tutorial is a direct investment in your career. You'll build better software and become a more effective developer. For a more detailed breakdown, check out our guide on TypeScript vs JavaScript benefits and trade-offs.

Alright, enough theory. Let's get our hands dirty and spin up a new project. The great news is that getting a React project started with TypeScript has never been easier. Modern tools have completely streamlined the setup, so you can skip the complex configuration and jump straight into coding.

We'll look at the two most common ways to kick off a new type-safe application.

It’s impossible to ignore how much the ecosystem has shifted. React's own documentation now shows TypeScript examples first, and Next.js has made it the default. This isn't an accident; it's a deliberate push that has given TypeScript incredible momentum. For new projects, it’s quickly becoming the path of least resistance.

This industry-wide adoption makes our lives a lot simpler. Let's start with what has become the go-to for building full-stack React apps.

Launching a Project with Next.js

Next.js has gone all-in on TypeScript. It's now the default for every new project, which means you don't even have to ask for it anymore—it just works out of the box.

Just pop open your terminal and run this command:

npx create-next-app@latest my-typescript-app

The installer will ask a few questions to configure your project, but you'll notice TypeScript is already enabled. Once it finishes, just cd my-typescript-app, run npm run dev, and you're good to go. You’ll have a live, type-safe Next.js app running in minutes.

Using Create React App with TypeScript

If you’re building a purely client-side application, Create React App (CRA) is still a solid option, even though it's not as actively maintained these days. Unlike Next.js, with CRA you still need to tell it you want TypeScript. For a deeper dive, check out our guide on how to build a React project with Create React App.

To get started, you’ll need to add a specific flag to the setup command:

npx create-react-app my-typescript-app –template typescript

This command creates a new React project with all the TypeScript dependencies and configurations handled for you. It generates a tsconfig.json file and sets up your initial components with the correct .tsx extension.

Decoding the tsconfig.json File

No matter which setup you choose, you'll find a tsconfig.json file sitting in your project's root. This file is the command center for the TypeScript compiler, telling it exactly how to check your code and turn it into JavaScript.

It can look a bit intimidating at first, but the defaults from Next.js and CRA are fantastic starting points. You really only need to be familiar with a few key options to get going.

Key Takeaway: The tsconfig.json file is your control panel for the TypeScript compiler. The default settings provided by modern frameworks are already optimized for React, so you can trust them.

Here are a few of the most important settings you'll see:

You honestly won't need to touch these settings much, if at all. The initial configuration gives you a rock-solid foundation for building a reliable app. This strong, pre-configured base is the perfect starting point for our typescript with react tutorial.

Applying Types to Core React Concepts

Alright, with the setup out of the way, let's get into the good stuff. This is where TypeScript stops being a configuration chore and becomes your everyday partner in building solid React applications, catching bugs before they happen and making your component APIs crystal clear.

The shift towards TypeScript in the React world isn't just a trend; it's a massive, community-driven move towards more stable code. The numbers speak for themselves. The State of JavaScript 2022 report found that over 80% of React developers have used TypeScript, with an 84.1% satisfaction rate. With tools like Create React App hitting over 2.3 million weekly downloads with built-in TypeScript support, it's safe to say type-safety is no longer optional—it's the standard. You can explore more about current React development trends on hypersense-software.com.

Typing Component Props

The first and most common thing you'll do is type your component props. Think of this as defining a contract for your component. It's the best way to guarantee that anyone using it provides the right kind of data, which wipes out a whole class of common bugs.

Imagine a simple JavaScript component.

Before: Plain JavaScript
// Greeting.js
const Greeting = ({ name, messageCount }) => {
return (


Hello, {name}!


You have {messageCount} new messages.



);
};
This works just fine, but there's nothing stopping another developer (or you, six months from now) from passing messageCount="five". That would lead to some weird, unexpected behavior at runtime.

Now, let's lock it down with a TypeScript interface. Interfaces are perfect for describing the shape of an object, which is exactly what props are.

After: TypeScript with an Interface
// Greeting.tsx
interface GreetingProps {
name: string;
messageCount: number;
}

const Greeting = ({ name, messageCount }: GreetingProps) => {
return (


Hello, {name}!


You have {messageCount} new messages.



);
};
Boom. With the GreetingProps interface in place, your code editor will immediately light up with an error if you try to use <Greeting /> with the wrong props. Your component is now self-documenting and way more resilient.

Typing State with useState

Next up in our typescript with react tutorial is state. While the useState hook is a workhorse, it's easy to accidentally change a state variable's type in plain JavaScript. TypeScript is often smart enough to figure out simple types on its own, but being explicit is always a good idea, especially as things get more complex.

Primitive State
For simple values, TypeScript's type inference usually gets it right.

// Good: Type is correctly inferred as 'boolean'
const [isOpen, setIsOpen] = useState(false);

// Better: Explicitly typed for maximum clarity
const [isLoading, setIsLoading] = useState(true);
Using the generic useState<boolean> is a small touch, but it leaves zero room for misinterpretation.

Object State
This is where explicitly defining types becomes essential. When your state is an object, you need to tell TypeScript what it's supposed to look like.

// UserProfile.tsx
interface User {
id: number;
username: string;
email?: string; // This property is optional
}

const UserProfile = () => {
const [user, setUser] = useState<User | null>(null);

// In a real app, you'd fetch this from an API
const loginUser = () => {
setUser({ id: 1, username: 'dev_user' });
};

if (!user) {
return ;
}

return

Welcome, {user.username}
;
}
Here, we've typed our state as User | null. This tells TypeScript that the user state can either be an object that matches our User shape or it can be null (like before a user logs in). This forces us to handle that null case, preventing a classic "cannot read properties of null" runtime error.

Typing Core React Hooks

Beyond useState, getting your types right for other hooks like useRef and useContext is crucial. These hooks are often interacting with things outside of React's direct control—like the DOM or global state—which makes type safety even more valuable.

Even the official React documentation has gone all-in on TypeScript, featuring it prominently in all their examples.

When the official docs make it a first-class citizen, you know it's the modern way to build.

Typing useRef
A useRef hook can point to a DOM element or just hold a mutable value. When it's for a DOM element, you need to tell TypeScript what kind of element it is.

// FocusableInput.tsx
import { useRef, useEffect } from 'react';

const FocusableInput = () => {
// Tell the ref it's for an HTMLInputElement and might be null
const inputRef = useRef(null);

useEffect(() => {
// TypeScript knows inputRef.current could be null, so we must check
if (inputRef.current) {
inputRef.current.focus();
}
}, []);

return ;
};
By defining the ref with useRef<HTMLInputElement>(null), TypeScript understands that inputRef.current is either an HTMLInputElement or null. This forces you to add that if check before trying to call .focus(), saving you from a potential crash.

Key Insight: Typing hooks like useRef and useState isn't just about data shapes. It's about accurately modeling your component's entire lifecycle, including its initial, loading, and final states.

Typing useContext
useContext is fantastic for avoiding prop drilling, and typing it ensures that any component consuming that context gets exactly what it expects. To dive deeper into what React actually renders, check out our guide on the differences between JSX.Element, ReactNode, and ReactElement.

Let's build a simple, type-safe theme context.

// ThemeContext.tsx
import { createContext, useContext, useState } from 'react';

type Theme = 'light' | 'dark';

interface ThemeContextType {
theme: Theme;
toggleTheme: () => void;
}

// Create the context, telling TS it might be undefined initially
const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

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

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

// A custom hook is the best way to consume the context
export const useTheme = () => {
const context = useContext(ThemeContext);
if (context === undefined) {
throw new Error('useTheme must be used within a ThemeProvider');
}
return context;
};
This pattern is robust and fully type-safe. The createContext call defines the "contract," the Provider supplies a value that honors it, and our custom useTheme hook gives us a safe way to access the context, even throwing a helpful error if we try to use it outside the provider.

Advanced Typing Patterns for Reusable Components

Once you've nailed down the basics of typing props and hooks, the real fun begins. It's time to move past the fundamentals and into the patterns that truly separate good React code from great, scalable code. This is how you start building components that you can reuse across projects and manage complex application states with total confidence.

We’ll kick things off by crafting components that are not only type-safe but also incredibly flexible. From there, we'll dive into advanced state management with useReducer, get a handle on typing user interactions, and finally, solve the age-old challenge of dealing with API data.

Crafting Generic Components

A truly reusable component shouldn't care what kind of data you give it. Think about building a custom dropdown, a data table, or even a simple list. You want it to work with an array of users, products, or whatever else you need, all while maintaining perfect type safety. This is exactly what generics are for.

Let's build a generic List component. Instead of locking our items prop into a rigid type, we'll use a type variable—you'll usually see it named T.

// GenericList.tsx
import React from 'react';

// 'T' is a placeholder for whatever type we pass in later
interface ListProps {
items: T[];
renderItem: (item: T) => React.ReactNode;
}

// We use 'T' again here to connect the component to the props interface
export const GenericList = <T,>({ items, renderItem }: ListProps) => {
return (


);
};
Pay close attention to the <T,> syntax in the component definition. That trailing comma is crucial in .tsx files; it tells TypeScript you're defining a generic, not writing a JSX tag.

Now, this GenericList can be used with any data structure, and TypeScript will automatically figure out and enforce the types for you.

// Example using an array of strings
<GenericList
items={['Apple', 'Banana', 'Cherry']}
renderItem={(item) => {item.toUpperCase()}}
/>

// Example using an array of objects
const products = [{ name: 'Laptop', price: 1200 }, { name: 'Mouse', price: 50 }];
<GenericList
items={products}
renderItem={(item) =>

{item.name} – ${item.price}
}
/>

If you tried to access item.price in the first example, TypeScript would immediately flag an error because it knows item is just a string. That’s the magic of generics—they give you flexibility without sacrificing safety.

Mastering Complex State with useReducer

When state logic starts getting complicated, a handful of useState calls can quickly become a mess. This is where useReducer really shines. Typing it correctly is a three-part process: define your state's shape, define the actions that can modify it, and then type the reducer function itself.

Let's see this in action with a simple counter that can increment, decrement, and reset.

// Counter.tsx
import { useReducer } from 'react';

interface CounterState {
count: number;
}

// Use a discriminated union for all possible actions
type CounterAction =
| { type: 'INCREMENT' }
| { type: 'DECREMENT' }
| { type: 'RESET' };

const initialState: CounterState = { count: 0 };

function reducer(state: CounterState, action: CounterAction): CounterState {
switch (action.type) {
case 'INCREMENT':
return { count: state.count + 1 };
case 'DECREMENT':
return { count: state.count – 1 };
case 'RESET':
return { count: 0 };
default:
throw new Error('Unhandled action type');
}
}

const Counter = () => {
const [state, dispatch] = useReducer(reducer, initialState);

return (


Count: {state.count}


<button onClick={() => dispatch({ type: 'INCREMENT' })}>Increment
<button onClick={() => dispatch({ type: 'DECREMENT' })}>Decrement
<button onClick={() => dispatch({ type: 'RESET' })}>Reset

);
};

This pattern is incredibly robust. By using a discriminated union for CounterAction, TypeScript can infer the shape of your action based on its type property. This makes it impossible to dispatch an invalid action like dispatch({ type: 'SOME_OTHER_ACTION' }).

Typing Event Handlers Correctly

Handling user events like clicks and input changes is a daily task in React. Instead of reaching for any or just guessing, you should use the specific event types that React provides. It's cleaner and gives you way better autocompletion.

Here’s a practical example:

// EventForm.tsx
import React, { useState } from 'react';

const EventForm = () => {
const [value, setValue] = useState('');

const handleClick = (event: React.MouseEvent) => {
console.log('Button clicked!', event.currentTarget.tagName);
// event.currentTarget is now correctly typed as an HTMLButtonElement
};

const handleChange = (event: React.ChangeEvent) => {
setValue(event.target.value);
// event.target is correctly typed as an HTMLInputElement
};

return (




);
};
By specifying the HTML element in angle brackets, like React.MouseEvent<HTMLButtonElement>, you give TypeScript enough information to provide full IntelliSense on the event object and its target.

Pro Tip: Get familiar with utility types like Pick, Omit, and Partial. They are fantastic for keeping your type definitions DRY (Don't Repeat Yourself). For instance, type UserUpdate = Partial<User> creates a new type where all properties from the User type are optional—perfect for an update form.

Typing Asynchronous API Data

Alright, let's talk about one of the most critical parts of any modern app: fetching and displaying API data. A rock-solid approach involves typing not just the data payload itself, but also the entire state of the request: loading, success, and error. This completely eliminates a huge class of runtime errors.

First, let's define the shape of the data we expect from the API.

// The shape of a single post from our API
interface Post {
id: number;
title: string;
body: string;
}

Next, and this is the key part, we'll model all the possible states of our data request.

// The possible states for any API call
type ApiState =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'success'; data: T }
| { status: 'error'; error: string };
Making this type generic with <T> means we can reuse this exact ApiState definition for fetching posts, users, products, or anything else.

Now, let's put it all together in a component that fetches some posts.

// PostsList.tsx
import { useState, useEffect } from 'react';

// Using the types we just defined
const PostsList = () => {
const [postsState, setPostsState] = useState<ApiState<Post[]>>({ status: 'idle' });

useEffect(() => {
setPostsState({ status: 'loading' });
fetch('https://jsonplaceholder.typicode.com/posts')
.then(response => {
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
})
.then(data => {
setPostsState({ status: 'success', data });
})
.catch(error => {
setPostsState({ status: 'error', error: error.message });
});
}, []);

switch (postsState.status) {
case 'loading':
return

Loading posts…

;
case 'error':
return

Error: {postsState.error}

;
case 'success':
return (

);
default:
return null;
}
};
This pattern is fantastic because it's exhaustive. The switch statement forces you to handle every state. Inside the 'success' case, TypeScript knows postsState.data is an array of Post objects. In the 'error' case, it knows postsState.error is a string. This isn't just about autocompletion; it's about making your UI fundamentally more reliable.

Migrating an Existing JavaScript Project to TypeScript

Taking over a large JavaScript codebase and trying to introduce TypeScript can feel like a monumental task. But it doesn't have to be a painful, all-or-nothing rewrite that brings development to a halt. The smartest approach is a gradual one, letting you strengthen your codebase one file at a time without breaking your workflow.

This is something we deal with all the time. Most real-world work isn't on shiny new projects; it’s on existing ones. The key is to get TypeScript set up to play nicely with your current JavaScript, allowing for a peaceful coexistence as you transition.

Enabling Incremental Adoption

Your first stop is the tsconfig.json file. There’s one setting in particular that’s your best friend for a gradual migration: "allowJs": true. This compiler option is the magic switch that tells TypeScript it’s perfectly fine for .js files to live in the same project as your new .ts and .tsx files. It lets your app compile even when only a small part of it has been converted.

After installing the core dependencies (typescript, @types/react, @types/node), you can begin. Don't fall into the trap of trying to convert everything at once. Pick a small, simple component—something with minimal logic or dependencies—and start there.

Your workflow for each file will look something like this:

This file-by-file strategy is, without a doubt, the safest way to migrate. It lets you deliver value incrementally and helps build confidence within your team. Every component you convert is a win, making the entire codebase more reliable.

Handling Missing Type Definitions

It won't be long before you import a third-party library that doesn't ship with its own types. Before you do anything else, check the DefinitelyTyped repository, which is a massive collection of community-maintained type definitions.

A quick npm install @types/library-name is often all you need to solve the problem.

But what happens when you can't find types for a package? You have a couple of options. For a quick fix to unblock yourself, you can create a declaration file (e.g., declarations.d.ts) and add declare module 'library-name';. This essentially tells TypeScript to treat the entire module as any, which silences the compiler errors and lets you move forward.

For a better long-term fix, you should write your own basic type declarations for the library. You don't need to type out the entire thing—just the functions or components you're actually using.

// src/types/some-library.d.ts

declare module 'some-untyped-library' {
export function someFunction(options: { id: string }): void;
// Add other functions or exports you use
}
This gives you type safety where it matters most, striking a practical balance between complete accuracy and the effort required.

This process flow diagram shows how you might apply these typing strategies to different parts of a React component, from creating a generic component to handling events and API data.

As the diagram shows, these TypeScript features work in concert to help you build a component that is typed from top to bottom.

Avoiding Common Migration Pitfalls

A successful migration is about more than just renaming files and adding types. It's about developing good habits and avoiding the common traps that can sabotage your efforts.

The Temptation of any
When you’re just starting, it’s incredibly tempting to use any to quickly silence errors. Try to resist this urge. Every time you use any, you're opting out of type checking for that variable, which defeats the whole purpose of using TypeScript. Think of any as an escape hatch for truly tricky situations, not your default tool.

Interface vs. Type
The interface vs. type debate can be a source of confusion. My rule of thumb is pretty simple:

For instance, type Status = 'loading' | 'success' | 'error'; is a perfect use case for a type alias.

Typing Higher-Order Components (HOCs)
HOCs have always been a bit tricky to type correctly because they inject props into the component they wrap. The key to getting this right is generics. By using a generic to represent the props of the wrapped component, you can create a flexible HOC that correctly passes through all the original props while adding its own, maintaining complete type safety from end to end.

Common Questions About React and TypeScript

As you start using TypeScript more in your React projects, you're bound to run into a few common head-scratchers. This section is here to tackle those frequent questions head-on, giving you some practical answers to keep you moving forward.

Think of this as a field guide for the typical forks in the road you'll face. These are the solutions and rules of thumb I've settled on after years of building type-safe React applications.

When Should I Use an Interface Versus a Type Alias?

This one comes up all the time. It's probably the most common point of confusion for developers new to TypeScript in React. While they can often be used interchangeably, having a consistent rule makes your code much easier to read and maintain.

My rule of thumb is simple: Use an interface when defining the "shape" of an object or a component's props. Use a type alias for everything else, especially for creating unions, intersections, or naming primitives.

For instance, an interface is a perfect fit for defining what a component expects. It's like a contract.

interface ButtonProps { label: string; onClick: () => void; }

A type alias, on the other hand, is great for defining a specific set of allowed values or combining other types.

type ButtonVariant = 'primary' | 'secondary' | 'ghost';

One of the key benefits of interfaces is that they can be extended, which is fantastic for building on top of base definitions. Type aliases are a bit more flexible for creating complex new types from existing ones. Sticking to this separation will bring a lot of clarity to your codebase.

How Do I Handle Libraries Without TypeScript Support?

Sooner or later, you'll find a great third-party library that, unfortunately, wasn't written in TypeScript and doesn't ship with its own types. Your first instinct might be to just slap a // @ts-ignore on it and move on, but please don't.

Before you do anything else, check the DefinitelyTyped repository. It’s a massive collection of community-maintained type definitions. A quick npm install @types/library-name will often solve the problem in seconds.

If you come up empty there, you have a couple of solid options:

Is React.FC Still Recommended?

For a long time, React.FC (or its longer version, React.FunctionComponent) was the standard for typing functional components. Times have changed, though, and the community has largely moved away from it. I've found that typing props directly on the function is a much cleaner approach.

The main issue with React.FC is that it implicitly includes children in your component's props. This is a problem if your component isn't designed to accept children, as it makes your props contract misleading.

Defining props explicitly is far more direct and leaves no room for ambiguity.

const MyComponent = ({ name, age }: { name: string; age: number }) => { ... };

While React.FC isn't officially deprecated and still works, typing your props directly is now considered a better practice. It makes your component's public API crystal clear from the start.

Keep building your skills with Next.js & React.js Revolution. We publish daily guides and tutorials to help you master the modern web. Check out our latest articles at https://nextjsreactjs.com.

Exit mobile version