REACT (https://www.kirupa.com/react/index.htm) BOOK (https://www.amazon.com/exec/obidos/ASIN/0134546318/kirupacom) Your React Learning Path by kirupa (https://www.kirupa.com/me/index.htm) | filed under Learning React (https://www.kirupa.com/react/index.htm) If you've ever searched for how to learn React, you've probably noticed that there is a lot of it. Components, JSX, props, state, hooks, effects, context, routing, Redux, TypeScript, Next.js, Server Components, and a bunch of other words that all sound equally important. Nobody tells you what order to learn them in, which ones to skip for now, or when you are allowed to say "I know React." That's what this tutorial is for. Think of it as the map that goes with the rest of the tutorials here. We'll look at the stages you will go through, what you should be able to build at the end of each one, the tutorials to read for it, and the things you can safely ignore until you actually need them. We'll also talk about how to get unstuck, and how to use an AI assistant to learn faster without picking up some very specific bad habits. Onwards! The Big Picture Learning React works best as a series of small stages, where each stage lets you build something you couldn't build before. Here is the whole path in one picture: [Image: A winding path of seven boxes. Stage 1 is JavaScript Basics, stage 2 is Components, JSX, and Props, stage 3 is State and Events, stage 4 is Effects, Forms, and Context, stage 5 is Data and Routing, stage 6 is TypeScript and Frameworks, and stage 7 is Testing and Shipping. Each box says what you can build at that stage, from scripts to a live URL.] (https://www.kirupa.com/react/images/react_learning_roadmap_144.png) A few things are worth pointing out. The path is mostly a line, because each stage really does build on the one before it. If you skip stage 3 and go straight to stage 5, you'll end up copying code that you can't change without breaking it. The middle three stages (components, state, and effects) are where most of React lives, and if you are comfortable there, you can build a surprising number of things. The last few stages are things you pick up as a project demands them, and not all at once. Let's walk through each stage. The Seven Stages Stage 1: Get Comfortable with JavaScript React is a JavaScript library, which means JavaScript is the floor that everything else stands on. You don't need to be a JavaScript expert. You do need to be comfortable with variables, functions, arrays, and objects, plus a small set of features that React code uses constantly: arrow functions, destructuring, the spread operator, map and filter, and modules. You also need a working knowledge of HTML and CSS, because JSX looks a lot like HTML and you will still style things with CSS. Here is a quick test. If you can read the following code and explain what it does without squinting, you're in good shape: const names = people .filter((person) => person.active) .map(({ name }) => name); It takes a list of people, keeps the ones marked as active, and ends up with just their names. If that looked like gibberish, that's fine, because there are two tutorials for exactly this: - What to Know Prior to Learning React? (https://www.kirupa.com/react/how_much_to_know_prior_learning_react.htm) covers how much HTML, CSS, and JavaScript is enough. - The JavaScript You Need for React (https://www.kirupa.com/react/javascript_for_react.htm) goes through the specific features that show up in React code, one small example at a time. What you can build: nothing in React yet, but I'd encourage you to make one small page with plain JavaScript (a to-do list with no libraries is a classic). It will make you appreciate what React does for you in the next stage. Stage 2: Components, JSX, and Props This is where you meet React itself. You'll learn what a component is, how JSX lets you write markup inside JavaScript, how to pass data into components with props, and how to turn a list of data into a list of elements. You'll also set up a real project using Vite, which is the tool that gives you a fast dev server and a build step. - Introducing React (https://www.kirupa.com/react/introducing_react.htm) explains what React is and the problem it solves. - Building Your First React App (https://www.kirupa.com/react/building_your_first_react_app.htm) gets something on screen with no build tools at all. - Easily Set Up Your React Dev Environment (https://www.kirupa.com/react/setting_up_react_environment.htm) creates a real Vite project. - Components in React (https://www.kirupa.com/react/components.htm) and Function Components (https://www.kirupa.com/react/functional_components.htm) are the building blocks of everything else. - Meet JSX...Again! (https://www.kirupa.com/react/meet_jsx_again.htm) and Styling in React (https://www.kirupa.com/react/styling_in_react.htm) cover the markup and how to make it look good. - Creating Complex Components (https://www.kirupa.com/react/creating_complex_components.htm) and Transferring Properties (https://www.kirupa.com/react/transferring_properties.htm) show how components nest and pass data down. - Going from Data to UI (https://www.kirupa.com/react/from_data_to_ui_in_react.htm) and Conditional Rendering in React (https://www.kirupa.com/react/conditional_rendering_in_react.htm) turn arrays and conditions into what the user sees. What you can build: pages made out of reusable pieces. A profile card, a pricing table, a product grid generated from an array, a list of articles where some entries show a "new" badge. Nothing here reacts to the user yet, but that's okay! Stage 3: State and Events Up until now, everything you've built has been a snapshot. State is what makes your UI change over time. You'll learn how to respond to clicks and typing, how to remember values between renders, and how React decides what to update on the screen. This is also where you meet hooks, starting with useState. - Events in React (https://www.kirupa.com/react/events_in_react.htm) is how your components react to clicks, keys, and everything else. - Meet React Hooks (https://www.kirupa.com/react/meet_react_hooks.htm) explains what hooks are and the two rules that go with them. - Dealing with State (https://www.kirupa.com/react/dealing_with_state.htm) is all about useState. What you can build: anything that responds to the user and remembers something. A counter, a light/dark theme toggle, a like button, an accordion, a tabbed panel, a color picker. If you can build a counter, you've learned the single most important loop in React: state changes, React re-renders, the screen updates. Stage 4: Effects, Forms, and Context Now your components start dealing with the world outside React and with each other. Effects let you do things like set up a timer or listen to the browser. Forms let you collect input. A reducer helps when state gets complicated, context lets you share data without passing it through every layer, and custom hooks let you reuse logic. By the end of this stage, you also learn how to think about a whole app, not just one component. - Effects with useEffect (https://www.kirupa.com/react/effects_with_useeffect.htm) and The React Component Lifecycle (https://www.kirupa.com/react/component_lifecycle.htm) cover when components appear, update, and go away. - Accessing DOM Elements (https://www.kirupa.com/react/accessing_dom_elements.htm) is for the moments when you need to talk to the browser directly. - Forms and Controlled Inputs (https://www.kirupa.com/react/forms_in_react.htm) is how you collect and validate what people type. - Managing State with useReducer (https://www.kirupa.com/react/managing_state_with_usereducer.htm) and Sharing Data with Context (https://www.kirupa.com/react/sharing_data_with_context.htm) handle bigger state and shared state. - Building Custom Hooks (https://www.kirupa.com/react/custom_hooks.htm) shows how to package up logic for reuse. - Thinking in React (https://www.kirupa.com/react/thinking_in_react.htm) walks through how to break a design into components and decide where state lives. - Building a Simple Todo List App (https://www.kirupa.com/react/simple_todo_app_react.htm) puts it all together. One piece of honest advice here: effects are the most overused feature in React. A lot of the time, when you reach for useEffect, the thing you actually need is a plain variable, an event handler, or a key. Read the effects tutorial slowly, and when you are about to write one, ask yourself whether something is really happening outside of React. If not, you probably don't need it. What you can build: real, useful apps. A todo list, a notes app that remembers things between visits, a signup form with validation, a shopping cart, a quiz. This is the stage where most people go from "following along" to "I can build my own thing." Stage 5: Data and Routing Most real apps load data from somewhere and have more than one screen. You'll learn how to fetch data from an API (and deal with loading and error states), and how to give a single-page app multiple pages using React Router. - Working with External Data (https://www.kirupa.com/react/working_with_external_data.htm) covers fetching, loading, errors, and cleanup. - Creating a Single-Page App using React Router (https://www.kirupa.com/react/creating_single_page_app_react_using_react_router.htm) adds navigation between pages. When you've built something real, you may run into an app that feels slow or an animation that isn't smooth. These tutorials are the ones to pull out at that point (and not before): - Creating a Smooth Sliding Menu (https://www.kirupa.com/react/smooth_sliding_menu_react_motion.htm) is a fun project that uses state and CSS transitions. - Avoiding Unnecessary Renders (https://www.kirupa.com/react/avoiding_unnecessary_renders.htm) and Keeping Your UI Responsive (https://www.kirupa.com/react/keeping_your_ui_responsive.htm) deal with performance, once you have a performance problem to deal with. What you can build: apps that talk to the internet. A weather app, a movie search, a GitHub profile viewer, a small blog with a home page, a list page, and a detail page. Stage 6: TypeScript and Frameworks Once you have built a few apps, you start to notice the pain points. Mistakes like passing the wrong kind of value to a component don't show up until the app is running. Managing routing, data loading, and server code by yourself becomes a lot of work. This is where TypeScript and frameworks come in, and also where you catch up on what is new in recent versions of React. - Using React with TypeScript (https://www.kirupa.com/react/react_with_typescript.htm) adds types to props, state, and events. - What's New in React 19 (https://www.kirupa.com/react/react_19_whats_new.htm), Suspense and Error Boundaries (https://www.kirupa.com/react/suspense_and_error_boundaries.htm), and Server Components and React Frameworks (https://www.kirupa.com/react/server_components_and_frameworks.htm) cover the newer parts of React. - Updating to Newer React Versions (https://www.kirupa.com/react/updating_react_version.htm) is for when you inherit an older project. What you can build: bigger apps that are easier to change without breaking, and apps that run partly on a server. Stage 7: Testing and Shipping An app isn't really done until other people can use it. This last stage is about making sure it works, that it works for everybody, and that it is actually on the internet. - Testing React Apps (https://www.kirupa.com/react/testing_react_apps.htm) shows how to write tests that catch mistakes for you. - Accessibility in React (https://www.kirupa.com/react/accessibility_in_react.htm) makes sure people using keyboards and screen readers can use what you built. - Debugging React Apps (https://www.kirupa.com/react/debugging_react_apps.htm) is a field guide to the errors you'll see (and I'd honestly read it earlier than stage 7). - Deploying Your React App (https://www.kirupa.com/react/deploying_react_apps.htm) takes you from npm run build to a live URL. What you can build: a thing that you can send to a friend as a link. That moment is hard to beat. What to Skip for Now Just as important as what to learn is what you can ignore. React comes with a lot of side doors, and some of them are real time sinks for beginners. Here is what I'd skip until a project asks for it. - Redux and other global state libraries. Between useState, useReducer, and context, you can build a lot. When you do hit the point where those get awkward, Introduction to Redux (https://www.kirupa.com/react/introduction_to_redux.htm), Using Redux with React (https://www.kirupa.com/react/using_redux_with_react.htm), and Simple Global State with Zustand (https://www.kirupa.com/react/simple_global_state_with_zustand.htm) will be waiting for you. - Class components. New code is written with function components and hooks. You may still run into classes in older projects, and Function Components (https://www.kirupa.com/react/functional_components.htm) has a section for reading them, but you don't need to write them. - Memoization (memo, useMemo, useCallback). These are tools for fixing a measured performance problem. Adding them everywhere by default makes your code harder to read for no benefit. The React Compiler can also handle much of this for you automatically. - Server Components and server-side rendering. They are real and they are important, but they make a lot more sense after you understand what a regular component does in the browser. - The perfect folder structure, the perfect CSS approach, the perfect state library. Pick something reasonable, build the thing, and change it later when you know more. Everybody does. Skipping doesn't mean never. It means you are making a conscious decision to not carry something around until you have a reason to. Build Something at Every Stage Reading tutorials gives you the feeling of understanding. Building something forces you to actually understand. The best way to make this stick is to finish a small project at each stage, and here is a ladder of projects that lines up with the stages above: [Image: A staircase of five projects going up and to the right. The first step is a counter that uses useState and events, then a todo list with lists, forms, and keys, then a data app with fetch and effects, then a multi-page app with routing and context, and finally a deployed app that is live on the web.] (https://www.kirupa.com/react/images/react_project_ladder_144.png) 1. A counter. Buttons that go up, down, and reset. This is a tiny project, but it locks in state, events, and re-rendering. The state tutorial (https://www.kirupa.com/react/dealing_with_state.htm) will get you there. 1. A todo list. Adding, completing, and removing items, with a text field. You'll use lists, keys, forms, and state in an array. The todo tutorial (https://www.kirupa.com/react/simple_todo_app_react.htm) walks through one if you want company. 1. A data-fetching app. Pick any free API (weather, movies, books, Pokémon, whatever makes you smile) and show the results with loading and error states. See Working with External Data (https://www.kirupa.com/react/working_with_external_data.htm). 1. A multi-page app. Take the previous app and add a list page, a detail page, and a way to navigate between them. React Router (https://www.kirupa.com/react/creating_single_page_app_react_using_react_router.htm) is the piece you need. 1. Deploy it. Put the multi-page app on a real URL using Deploying Your React App (https://www.kirupa.com/react/deploying_react_apps.htm). This part is the most fun, because suddenly your project is real. A good rule is to finish each project, even if the result is a little ugly. A finished small project teaches you more than an ambitious one that you abandon at 60%. Once you have the ladder behind you, make something that you personally want to exist. That's where the learning really takes off. How Long Does This Take? I wish I could give you a number, but anything I told you would be made up. People learn at different speeds, they come in with different backgrounds, and they have different amounts of time. What I can tell you is how effort tends to work. Short and regular beats long and rare. Thirty to sixty minutes most days will take you further than one long marathon on a weekend, because your brain needs time between sessions to move ideas into long-term memory. Stage 1 can feel quick if you've written JavaScript before, and stages 2 and 3 are usually where things click fast, since you see results on screen right away. Stage 4 is where most people slow down, because effects, forms, and context have a lot of subtle details. That's normal. If it feels like a wall, you are not doing it wrong. You can also tell where you are without a calendar. You are ready for the next stage when you can build the "what you can build" project from the current stage without following a tutorial line by line. It's totally fine to peek at documentation or an old project of yours while doing it. What matters is that you can get from a blank file to a working result. What React Is (and What It Isn't) One thing that confuses a lot of people is what React actually covers. React is a library for building user interfaces. It gives you components, state, and a way to turn those into what's on screen. That's it. It doesn't come with a router, a way to load data, a build system, or a server. To build a complete app, you combine React with other pieces, and the question of which pieces is where frameworks come in. There are three common ways to start a new React project: - A Vite single-page app. You get React, a fast dev server, and a build step, and you add the rest (like React Router) yourself. Everything runs in the browser, and the result is a folder of static files you can put anywhere. This is what this guide uses, because it lets you see how React works without a framework adding its own rules on top. - React Router in framework mode. This is React Router with Vite, plus extra features like server-side rendering and data loading built into the routes. - Next.js. A full-stack framework built around React with file-based routing, server rendering, and Server Components. The official React docs recommend using a framework when you start a new app or website that you plan to take to production, and say that a build-it-yourself setup is a good fit for learning the basics. I agree with both. Learn on a plain Vite project, because everything you learn there carries over, and when a project needs server rendering, SEO-friendly pages, or built-in data loading, look at a framework. Server Components and React Frameworks (https://www.kirupa.com/react/server_components_and_frameworks.htm) will help you decide. You may also see references to Create React App. It was the standard way to start a React project for years, but it's deprecated, so you'll want to use Vite or a framework instead. When You Get Stuck You will get stuck. Everybody does, and it doesn't mean you aren't cut out for this. Here is what I do, in roughly this order: - Read the error message, all of it. React's messages are a lot better than they used to be. They often tell you exactly what's wrong and sometimes how to fix it. Debugging React Apps (https://www.kirupa.com/react/debugging_react_apps.htm) goes through the most common ones. - Make the problem smaller. Comment out half of your component. If the bug goes away, it was in that half. Keep going until you've found the line. - Look at what's actually happening. Add a console.log, or open the React DevTools in your browser and look at the props and state of the component that's acting up. Very often, a value isn't what you thought it was. - Remember the usual suspects. Mutating state instead of replacing it, forgetting a key, an effect that runs too often, or a value that is out of date inside a closure. Each of these has its own tutorial section, and the JavaScript primer (https://www.kirupa.com/react/javascript_for_react.htm) explains the JavaScript behind a few of them. - Take a break. This sounds like a cliche, but it works. A lot of bugs are solved in the shower. - Ask for help, with a small example. Post your question on the kirupa.com forums (https://forum.kirupa.com) with the smallest piece of code that still shows the problem, what you expected, and what happened instead. Writing the question often leads you to the answer before anyone replies. Learning React with an AI Assistant Chances are good that you're going to learn with an AI assistant sitting next to you, and that can be a great thing. It's like having a patient friend who has read a lot of code and never gets tired of your questions. To get the most out of it, you need to know what it's good at and where it tends to go wrong. Where an Assistant Helps - Explaining. Paste in a piece of code and ask "what does this do, line by line?" This is great for the weird-looking parts, like a chain of map and filter with destructuring. - Reviewing your code. After you've written something yourself, ask it what could go wrong or what could be simpler. Try to write first and review second, so you're learning and not just collecting answers. - Comparing approaches. "When would I use useReducer instead of useState here?" is a better question than "write this for me." - Generating tests. It is good at drafting tests for a component you wrote, which you can then read, run, and adjust. See Testing React Apps (https://www.kirupa.com/react/testing_react_apps.htm) for what good tests look like. - Explaining errors. Paste in the full error and the code it came from, and ask what it means. The Outdated Patterns to Watch For Assistants learn from a large pile of code, and much of that pile was written years ago for older versions of React. This means they can hand you code that works but isn't how you'd write it today. Here are the ones I see most often, so you can spot them: - Class components. If you see class Something extends React.Component or this.setState in new code, it's the old style. Ask for a function component with hooks. - An effect for everything. Assistants love useEffect. Anything that can be calculated from props and state during render doesn't need one. - forwardRef. In React 19, ref is a regular prop that function components can receive directly, so you rarely need forwardRef anymore. - Create React App. If it tells you to run npx create-react-app, it's using stale instructions. Use Vite (or a framework) instead. - Old rendering and typing leftovers. Things like ReactDOM.render (replaced by createRoot), PropTypes (removed from React 19), and defaultProps on function components (use default parameter values). - Missing keys. It might render a list with map and forget the key prop, or use the array index as the key when items can be reordered or removed. - useMemo and useCallback everywhere. Often added out of habit, and not because anything is slow. The one I want to show you is the second one, because it's the sneakiest. Here is a list that filters itself as you type, written the way an assistant (or an enthusiastic beginner) might write it: function FruitList({ items }) { const [query, setQuery] = useState(""); const [filtered, setFiltered] = useState(items); useEffect(() => { setFiltered(items.filter((item) => item.includes(query))); }, [items, query]); return (
setQuery(e.target.value)} />
); } This works, but it does more than it needs to. The filtered list is a copy of data we can figure out from items and query. By storing it in state and updating it in an effect, we make React render twice for every keystroke: once when the query changes, and again after the effect sets the filtered list. I tried this out, typing a single letter into each version, and the effect version rendered two times while the version below rendered once. Here is the same thing, written without the extra state and the effect: function FruitList({ items }) { const [query, setQuery] = useState(""); const filtered = items.filter((item) => item.includes(query)); return (
setQuery(e.target.value)} />
); } That's the whole fix: filtered is now a plain variable that is recalculated on each render. Same behavior, less code, one fewer thing to keep in sync. Learning to spot this kind of thing is a big part of getting good at React, and Thinking in React (https://www.kirupa.com/react/thinking_in_react.htm) goes deeper on it. Read the Code You Accept The biggest risk with an assistant isn't that it will give you bad code. It's that it gives you code that works, and you never find out why. If you accept it without reading it, you'll end up with an app that you can't change when something goes wrong, which is a bad place to be. A few habits help. Type out or at least read through every line before you keep it. If there's a line you don't understand, ask what it does and then check the answer against the official React docs (https://react.dev), since the docs are the source of truth. Run your project's linter, because it catches a surprising number of hook mistakes. And once in a while, close the assistant and build a small thing completely on your own. That's how you find out what you've actually learned. How This Guide Relates to react.dev The official React documentation lives at react.dev (https://react.dev), and it's excellent. It has an interactive tutorial, a deep set of guides on how to think in React, and a complete reference for every hook and API. When you want to know exactly what an API does, that is where to go, and it's always kept up to date with the latest version of React. This guide has a different job. It's a companion that walks you through things in a particular order, with a lot of examples and a conversational tone. Where react.dev is the reference you look things up in, these tutorials are the place to build up your understanding. Using both together works really well: read a tutorial here to get the idea and build something, and then look at the matching page on react.dev to see the official take and the details. Conclusion Learning React is a lot easier when you know the order. Start with JavaScript, then components and JSX, then state and events. Move on to effects, forms, and context, and then data and routing. When you've built a few things, TypeScript, frameworks, testing, and deployment will be waiting for you. At each stage, build something small and finish it, and don't worry about the topics you've chosen to skip, because they'll still be around when you need them. An AI assistant can make you faster, as long as you read what it gives you and keep an eye out for the outdated habits we looked at. And when you get stuck (you will!), shrink the problem, look at what's really happening, and ask for help with a small example. You now have a map. Let's take the first step. Before you write any React, it's worth knowing how much HTML, CSS, and JavaScript you need to have in your toolbox. Next tutorial: What to Know Prior to Learning React? (https://www.kirupa.com/react/how_much_to_know_prior_learning_react.htm)