Getting React to Work in Your Actual Projects
The first time you install React and try to make something that doesn't break on the console, you spend about four hours fighting bundler configuration before writing a single line of real application code. This part hasn't changed much since 2019, even though the tooling has gotten better. I'm going to walk through what actually matters, skipping the fluff. You need Node.js installed. Version 18 or later. Check with node -v in your terminal. If you get a version mismatch error when running create-react-app, that's why. Don't overthink this step. It takes about thirty seconds. Create a new project with a modern setup. The current recommended approach is using Vite instead of Create React App, which is still maintained but genuinely slower to build and no longer the default recommendation from the React team. Run npm create vite@latest my-app -- --template react. Then navigate into the directory and run npm install followed by npm run dev. You should see a development server running at localhost:5173.
Understanding JSX Before You Write It
JSX is JavaScript syntax that looks like HTML but compiles down to regular JavaScript function calls. Every <div className="wrapper"> becomes React.createElement("div", { className: "wrapper" }) behind the scenes. The reason class uses className instead of class is because class is a reserved keyword in JavaScript. This trips up everyone at least once during their first week. You can embed any JavaScript expression inside JSX by wrapping it in curly braces. {user.name} renders the name property. {2 + 2} renders 4. {items.map(item =>{item})} renders a list. You cannot put statements inside braces though, only expressions. An if statement won't work there. Use a ternary operator instead: {isLoading ? Loading... : Data}.
Components and How They Actually Render
A component is just a JavaScript function that returns JSX. That's it. Here's a minimal one: function Greeting({ name }) { return <h1>Hello, {name}</h1>; } Component names must start with an uppercase letter. If you write function greeting() and try to use <greeting />, React will treat it as a custom HTML tag and throw a warning. This has cost me at least two debugging sessions I'll never get back.
When React renders a component, it calls your function, captures the returned JSX, and puts it on the screen. When state changes, it calls the function again with the new state and diffs the result against the previous output. This diffing process is called reconciliation. React uses a virtual representation of the DOM to figure out what actually changed, then updates only those parts of the real DOM. This is why React is fast for most cases, though the virtual DOM overhead does add up in extremely large lists where you should be using virtualization libraries instead.
Get the Full Details
State Management with useState
The useState hook is how components remember things between renders. You call it inside your component function and it returns an array with two elements: the current value and a function to update it. const [count, setCount] = useState(0); Every time you call setCount, React schedules a re-render. The old state value is preserved across renders because it's captured in the closure of your component function. This is important to understand because if you're reading state inside a setTimeout or an event handler that was set up in a previous render, you might be reading stale values. I ran into this exact problem last year when building a form validation system where the validation logic was running against outdated state because the event listener was capturing the initial render's closure. The fix was wrapping the handler in useCallback with the proper dependency array, or using the functional update form: setCount(prev => prev + 1).
You can have multiple state variables. There's no rule saying you need to combine them into a single object, though for related fields like a form with name, email, and password, grouping them into a single state object is usually cleaner.
Side Effects with useEffect
useEffect runs code after the component renders. It's commonly used for data fetching, subscriptions, and manually manipulating the DOM. The second argument controls when it runs again. Omit it and it runs after every render. Pass an empty array and it runs only once after the initial render. Pass [dependency] and it runs after the initial render and whenever that dependency changes. Here's a realistic pattern for fetching data: useEffect(() => { fetch('/api/data').then(r => r.json()).then(setData); }, []);
The problem most people hit with useEffect is the waterfall effect, where you need data from one endpoint to call another, creating a chain of dependent requests. The workaround is to either structure your API to return everything in one call, or use a library like TanStack Query to handle the dependency resolution and caching for you. I wrote a custom hook that looked like three nested effects when I could have just made a single API call that returned both resources. That took me six hours to debug because the data was arriving in the wrong order and causing render errors.
Props and Component Composition
Props are how you pass data from parent to child. They're read-only. A child component should never modify its props directly. If you find yourself wanting to change a prop, that data should probably be state in the parent component instead, and you pass a callback down as another prop. For example, a parent manages a list of todos. It passes the list and an onAdd function to a TodoList component. TodoList renders each item and calls onAdd when the user submits. The parent updates its own state in response. This unidirectional data flow is what makes React predictable. When you start mutating props directly or managing state deep inside child components, your app becomes difficult to debug because you can no longer trace where a value changed.
Lists and Keys
When rendering a list, every element needs a unique key prop. React uses keys to track which items have changed, been added, or removed. Without stable keys, React has to do a full re-render of the list on every change, which is slow and can cause bugs with input focus and animation state. Never use array index as a key if the list can be reordered, filtered, or have items inserted or deleted. The index changes when the list shifts, and React will incorrectly reuse components. Use a stable identifier from your data instead, like a database ID or a UUID. I learned this the hard way when building a drag-and-drop task board where items were constantly being reordered. Using index as the key caused the wrong task cards to swap positions visually while the data underneath stayed correct, making it look like the UI was completely broken when actually it was just React matching elements to the wrong data rows.
Conditional Rendering Patterns
There are several ways to conditionally show or hide content in React. The most common is the ternary operator inside JSX. You can also use the && operator for simple cases where you only need to show something when a condition is true. {isActive && <div>Content</div>}. This works because when isActive is false, React renders false, which produces nothing in the DOM. There's also the option of extracting conditional logic into separate components. Instead of nesting three levels of ternary operators in your return statement, define sub-components for each state and compose them. This makes the code readable and testable. I've seen codebases where the JSX in a single component's return statement ran over two hundred lines because of nested conditionals. Splitting those into small presentational components cut the file down to about sixty lines and made it significantly easier to reason about.
Handling Events
React events use camelCase naming. onClick not onclick. onChange not onchange. You pass a function reference, not a string. <button onClick={handleClick}> not <button onClick="handleClick()">. Event handlers in React are subject to event delegation. React attaches a single listener at the document level for most events and routes them to the correct component. This is why you don't need to worry about manually attaching and detaching listeners, but it also means you can't rely on standard DOM event bubbling behavior in all cases, particularly with portals or when using certain third-party libraries that manipulate the DOM directly outside of React's control.
Forms in React
Controlled components are the standard approach. Every form input has its value tied to React state, and an onChange handler updates that state. This gives you full control over the input at any time, which is necessary for validation, formatting, and conditional field behavior. For simple forms, useState is sufficient. For complex forms with many fields, validation rules, and async submission, you should use a library. React Hook Form is the most popular option. It minimizes re-renders by using refs for most of its internal state and only triggers re-renders when you explicitly call its submit handler. I switched a project from manually managing form state with useState to React Hook Form and saw the render count drop from roughly forty per input event to three or four total, spread across the entire form lifecycle. That difference is significant when you have a form with twenty fields and real-time validation running on every keystroke.
When useState Isn't Enough
Sometimes you need more complex state logic. The useReducer hook handles this by managing state through a reducer function, similar to how Redux works but built into React. It's useful when the next state depends on the previous state in complex ways, or when you have multiple related values that need to be updated together. However, don't reach for useReducer just because your state object is large. If you're just setting individual fields independently, useState with separate variables or a single useState with an object is fine. useReducer adds boilerplate that isn't worth it for simple cases. The React documentation itself recommends useState as the default and useReducer for cases where state logic is complex or the next state depends on the previous one.
Context and Global State
React Context lets you pass data through the component tree without threading props manually through every level. It's useful for things like theme, authentication status, and language preference. But Context causes every consumer to re-render when the value changes, regardless of whether that particular consumer uses the changed part of the value. This is a well-known performance gotcha. The workaround is to split your context into smaller pieces. Instead of one giant AppContext with everything in it, create separate contexts for theme, user, and locale. Each component only subscribes to the context it actually needs. I built a dashboard application once with a single massive context and watched the page become sluggish after adding twelve widgets, each of which re-rendered on every state change even though nine of them didn't depend on the changed data. Splitting the context into three separate ones eliminated the problem entirely. For application-scale state management, Zustand or Jotai are lighterweight alternatives to Redux that don't require as much boilerplate. Redux Toolkit is still the right choice if you need time-travel debugging, middleware for side effects, or a large team that needs strict conventions around state mutations.
Custom Hooks
Once you find yourself writing the same logic in multiple components, extract it into a custom hook. Any function that starts with use and calls other hooks is a custom hook by React convention. There's nothing special about the name itself, but linter rules and React's own hook validation rules depend on it. A practical example is a hook for handling debounced input. You'd wrap useState, useEffect, and useRef to create a reusable debounce pattern. This is something you'll end up writing in almost every project, and having it as a custom hook means you don't have to think about the implementation details each time.
Performance Basics
Most React performance problems come from one of three things: too many re-renders, overly large component trees, or expensive computations during render. React.memo wraps a component to prevent re-renders when its props haven't changed. It's useful but not a silver bullet. Passing new objects or functions as props will still cause memoized components to re-render because the reference comparison fails. The useMemo hook caches the result of expensive calculations between renders. The useCallback hook caches function references between renders. Use both sparingly. Profile first, optimize second. Adding useMemo to every calculation in your component without measuring the actual bottleneck usually makes the code harder to read without improving performance. I reviewed a codebase last year where someone had wrapped twelve useMemo calls in a single component, and the bundle was larger and the render path was slower because of the overhead of tracking all those dependencies. Removing eight of them and fixing the actual re-render cause at the parent level was the real fix.
Testing What Matters
Unit test your custom hooks and utility functions. Integration test your components using a library like React Testing Library, which encourages testing from the user's perspective rather than testing implementation details. Don't test that a button has a specific CSS class or that a div contains certain text. Test that clicking the button triggers the expected outcome, like a success message appearing or a form submitting. Snapshot testing is fine for static markup but unreliable for anything that changes frequently. I stopped using snapshot tests about three years ago because the maintenance cost outweighed the value. A failing snapshot test tells you nothing about whether the behavior is correct, only that the output changed. That's noise, not signal.
Common Pitfalls to Avoid
Don't put asynchronous operations inside the render body. Don't modify state directly. Don't create new arrays or objects inline in JSX without memoizing them if they're passed to memoized children. Don't nest useEffects unnecessarily. Don't overuse context. Don't ignore the linter rules that React and ESLint provide. The lint rules exist for a reason. The exhaustive-deps rule on useEffect catches missing dependencies before they become bugs in production. The rules-of-hooks rule catches misplaced hook calls that silently break your application. Follow them. I've seen senior developers push back on the exhaustive-deps rule as overly strict, and every single time they did, there was an actual missing dependency that caused a stale closure bug six months later when the feature grew in complexity.
What Comes After the Basics
Once you're comfortable with the core concepts, the next steps are routing with React Router or Next.js, data fetching with TanStack Query, and building a design system with reusable components. Next.js adds server-side rendering, static generation, and file-based routing, which changes how you think about data flow significantly. The React fundamentals stay the same, but the patterns shift when you're rendering on the server and hydration is involved. Read the official React documentation. It's been rewritten to be clearer and more practical than it was five years ago. The old docs assumed you already understood functional programming concepts. The new ones walk through the reasoning behind each API decision. It's worth the time.
