React Js Practice Exercises

How to Actually Learn React by Doing It

The reason most people get stuck in React is that they watch tutorials without building anything themselves. You can watch someone build a todo app for six hours and still not know how to set up state in your own project when things go wrong. The gap between watching and doing is where people fall off. I have seen it happen repeatedly. The method that actually works is setting up a real project and working through exercises that force you to solve problems, not just copy code. Let me walk you through a practical approach and some specific exercises I think are worth your time.

React Js Practice Exercises

Setting up the environment. Use TypeScript and Vite. Create React App is dead and anyone telling you to use it is behind the times. Run npx create-vite@latest my-app --template react-ts and install the dependencies. That is your starting point. Keep it minimal. Do not add testing libraries, styling frameworks, or routing until you actually need them. Bloat kills your ability to debug. Exercise one: a controlled form with validation. Build a signup form that captures name, email, and password. Handle every input change through state. Add validation rules inline: the email must contain an @ symbol, the password must be at least eight characters, and the name cannot be empty. Display error messages next to each field. The point here is learning how controlled components actually work under the hood, not just memorizing syntax. I spent about two days on this exercise when I first learned React. The problem was that my error messages would flash briefly on screen and then disappear when I submitted the form. I spent hours chasing a bug that turned out to be my state update being batched differently than I expected because I was calling setErrors and setValue in the same event handler. The fix was wrapping the second call in useEffect so React could flush the state updates separately. This is the kind of thing you only learn by hitting it.

Exercise two: a fetch-based dashboard. Pull data from a public API like JSONPlaceholder and display it in a table. Add search filtering and pagination. Handle loading states and error states. The critical part here is structuring your fetch logic so it does not re-run on every render. Use a dependency array on your effect hook and include the search parameter and page number in that array. If you do not do this, your component will make hundreds of requests and your API key will get rate-limited within minutes. Exercise three: a context-based state manager. Build a shopping cart where items live in a context rather than being passed as props through multiple levels. Create separate components for the product list, the cart sidebar, and individual item quantity controls. This exercise forces you to think about prop drilling as a real problem instead of an abstract concept. You will discover that context is not a silver bullet for state management. After this exercise, move on to Zustand or Jotai for anything beyond simple cases. Exercise four: custom hooks. Extract your fetch logic from exercise two into a reusable custom hook called something like useFetchData. It should return the data, a loading boolean, and an error message. Pass it a URL and optional parameters. Then refactor your dashboard component to use this hook. This is where you start thinking about abstraction in React. It makes your components thinner and your logic easier to test.

Here is a counter-intuitive insight that most tutorials skip: stop trying to put everything in state. If a piece of data only changes when the user explicitly triggers an action, and you do not need to persist it across navigations, consider whether you actually need React state for it. Sometimes a regular JavaScript variable inside the component scope is sufficient, especially for temporary UI state like whether a modal is open during a single render cycle. The habit of reaching for useState first is the most common beginner mistake I see in code reviews. Another nuance people miss is that useEffect runs after the browser paints, not before. If you are using it to measure DOM dimensions or trigger animations, you might see a layout flicker. The solution is using a ref to access the DOM element directly instead of relying on effect timing. I lost about three hours debugging a chart library that rendered at the wrong size because I was reading offsetWidth inside a useEffect on the first render. Moving the measurement to a useLayoutEffect fixed it instantly.

Where These Exercises Fall Short

No set of exercises will prepare you for the messy reality of a large codebase. Practice exercises tend to isolate concepts cleanly, which means they do not teach you about the friction that comes from sharing state between ten different components, dealing with legacy code, or coordinating between a backend team and a frontend deadline. After you finish these exercises, the next step is building something that is slightly too big for your current skill level. A full dashboard with authentication, a small e-commerce flow, or a real-time chat interface will expose gaps in your understanding that practice exercises cannot. If you want structured exercises with built-in tests, check out the official React documentation examples section or look at Scrimba's free React course, which includes interactive coding challenges. FreeCodeCamp also has a React curriculum with project-based exercises. These resources are solid starting points before you move to building your own projects. The exercises listed above will take roughly two to four weeks if you are working on them part-time alongside other commitments. If you dedicate focused time, maybe three or four hours a day, you can compress that into ten days. The timeline depends entirely on whether you are actually writing the code yourself or just following along passively. Writing it yourself is the only thing that matters. Everything else is just noise.