Chapter 29 — Introduction to React (concepts)

Section 1 — What React is, at concept level

React is a JavaScript library for building user interfaces from components. Instead of writing a page as a single document that you edit directly whenever something changes, you describe components, small pieces of interface such as a button, a card, or a list, and React assembles them into the page and keeps the display in sync with your data. When the data changes, React updates only the parts of the page that need to change.

React is a library, not a complete framework, which means it focuses on the interface layer: how components are defined, how they receive data, and how they update. Other concerns, such as fetching data, routing between pages, and form handling, are handled by additional libraries or by code you write, chosen to fit the project. That focus is deliberate: React does one job, the interface, and it does it through components. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a React application might consist of a header component, a list component, and a card component, composed together like building blocks. Each component is a JavaScript function that describes what it should display, and React turns those descriptions into the page the user sees. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is thinking of React as a different language. It is JavaScript, using JavaScript functions, values, and logic, plus a few ideas and a special syntax that this chapter explains at concept level. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Try it now: make a tiny page with two or three elements, apply this idea to them, and compare the result with a version that does not use it. Notice what got easier, what got harder, and what you would want to change next time. That comparison is the real lesson, and it will guide your choices on larger pages.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 2 — Why React was created

React was created to solve a problem that grows with interactive pages: keeping the display consistent with the data behind it. In a page built by directly editing elements, every user action may require several separate edits to different parts of the page, and it is easy to update one part and forget another, leaving the screen in a contradictory state. As pages grew more interactive, with lists that filter, forms that validate live, and dashboards that update constantly, that manual updating became the main source of bugs. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

React's answer is to change the direction of the work. Instead of writing instructions for how to update the page step by step, you describe what the page should look like for a given set of data, and React works out the updates when the data changes. That description, called declarative programming, is easier to reason about, because the code states the intended result, not a sequence of edits. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a list that should show only matching items can be described as the items that match the search, and React will add or remove list entries as the search changes. You do not write separate code for adding and removing; you describe the result, and React handles the transition. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is trying to use React as if it were direct page editing, reaching in to change elements by hand. That fights the library's model and reintroduces the inconsistency it was designed to prevent. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

For practice, take an existing practice page and rework one section using this idea, keeping the visible result the same. If the page looks identical but the code is clearer or shorter, the rework was worthwhile. If the result changed unexpectedly, you have found a gap in your understanding worth closing before you rely on the idea in a bigger project.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 3 — Declarative versus imperative UI

Declarative user interface code describes what the interface should be, while imperative code describes how to change it step by step. An imperative approach to showing a message might say: find the message element, change its text, remove a hidden class, and add a visible class. A declarative approach says: when this condition is true, show this message, and leaves the steps to the library. The difference matters most as interfaces grow, because declarative code stays readable while imperative code accumulates steps. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

Declarative code is easier to debug because the display is a function of the data: if the screen is wrong, the data or the description is wrong, and there are only two places to look. Imperative code can be wrong in any of its steps, and the steps may have run in an order that is hard to reconstruct. That is why modern interface libraries, including React, favour the declarative style, even though it requires a shift in thinking for developers used to direct editing. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a declarative description of a button might be: show a loading label while saving, and the normal label otherwise. The condition is visible in the code, and the two states are both designed, rather than one being the result of a sequence of edits. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is mixing the two styles, describing most of the interface declaratively but patching one element imperatively when it misbehaves. That patch will be overwritten on the next update, producing a bug that appears and disappears mysteriously. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

A helpful exercise is to build the same small component twice: once with this approach and once without it. Put the two versions side by side and judge them on readability, ease of change, and behaviour on a narrow screen. There is rarely one winner for every situation, and learning when each approach wins is the skill that matters.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 4 — Components in React

In React, a component is a JavaScript function that returns a description of what should appear on the page. That description is written in a syntax that looks like HTML, which you will meet shortly as JSX, but it is produced by a function, which means it can use JavaScript logic: variables, conditions, and lists. A component can be as small as a button or as large as a whole page section, and components compose by using other components inside their descriptions. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

The function idea is important, because it means a component is reusable logic, not a copied block of markup. Calling the same component function with different inputs produces different outputs, and the component's internal logic is written once. It also means components can be tested like functions: give them inputs, check their outputs, and confirm they behave correctly in each case. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, a greeting component might be a function that accepts a name and returns a heading containing that name. Using it with different names produces different headings, all from one definition, and the logic for formatting the greeting lives in exactly one place. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is writing a component as a single large function that does everything on a page, instead of breaking it into smaller components. Small components are easier to understand, test, and reuse, just as small functions are. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

To make this stick, add the idea to your next practice project in exactly one place, and keep a short note about why you chose it there. Later, when you review the project, that note will tell you whether the choice paid off. Over several projects, those notes become a reliable personal guide to what works for you.

Check: How would you check your own work after applying the idea in this section?

Section 5 — JSX: the idea, not the syntax rules

JSX is a syntax extension for JavaScript that lets you write markup-like code inside JavaScript, so that a component's output looks like the HTML it will produce. Instead of building page elements with long function calls, you write something resembling <h1>Hello</h1> inside your component, and a build tool converts it into the JavaScript calls that create those elements. JSX is not HTML, and it is not a string of HTML: it is JavaScript syntax that describes elements, and it can contain JavaScript expressions inside curly braces. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

The reason JSX exists is readability. A component's output is easier to understand when it looks like the structure it produces, with nesting visible as nesting, than when it is a nest of function calls. The curly-brace expressions are the bridge: they let you insert a variable, a calculation, or a conditional result into the markup, so the description can vary with data while remaining readable as structure. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a component might return <p>Welcome, {name}</p>, where the braces insert the value of the name variable into the paragraph. The markup shows the structure; the braces show where data enters it. That combination is the essence of JSX. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is treating JSX as HTML and being confused when an HTML attribute or habit does not work the same way. JSX follows JavaScript rules in places, such as its handling of certain attribute names, so learn it as its own syntax, not as HTML pasted into JavaScript. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Practice deliberately: create a small test page, apply the idea, break it on purpose by changing one value, and then fix it. The break-and-fix cycle teaches you the boundaries of the idea far faster than reading alone, and it builds the calm debugging habit that professional work depends on.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 6 — The virtual DOM idea

The virtual DOM is React's way of updating the page efficiently. Instead of changing the real page directly on every data change, React keeps a lightweight, in-memory representation of what the page should look like, called the virtual DOM. When data changes, React builds a new virtual representation, compares it with the previous one to find exactly what changed, and then updates only those parts of the real page. That comparison step is called diffing, and the update step is called reconciliation. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

The benefit is not that the virtual DOM is faster than a direct edit in every single case; a single direct edit can be faster. The benefit is that developers no longer need to work out, by hand, the minimal set of edits for a complex change. React does that work, reliably, for every change, which removes a whole class of inconsistency bugs. It also means the developer's job is to describe the desired result, not to optimise the update steps. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, when one item in a list of fifty changes, React's comparison finds that single item and updates only it, rather than rebuilding the whole list. The developer described the new list; React worked out the minimal update. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is thinking the virtual DOM is a separate page the user sees. It is an internal working model; the user always sees the real page, which React keeps in sync with the model. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 7 — Props in React

Props in React are the inputs passed to a component, supplied as attributes in JSX and received by the component function as an object. A parent component passes data down to a child by writing attributes on the child's element, and the child reads those values to decide what to display. Props flow in one direction, from parent to child, which makes data flow predictable: to understand what a component displays, you look at what its parent passed it. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

One-way data flow is a deliberate design choice. Because data does not flow back up through props, a child cannot silently change its parent's data; it can only announce events, which the parent may handle by changing its own state and passing new props down. That cycle, props down and events up, is the same pattern you met in component thinking, now made concrete by React's mechanism. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a card component might receive a title and a summary as props, written as <Card title="Hello" summary="A short text" />, and render them in its markup. The same card component, given different props, renders a different card, without any change to its definition. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is mutating props inside a component, trying to change the values it received. Props should be treated as read-only; if a value needs to change, the owner of that data should change it and pass new props down. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 8 — State in React

State in React is data that a component owns and can change over time, such as whether a menu is open, what a user has typed, or which item is selected. When state changes, React re-renders the component, producing a new description of its output, and updates the page to match. That automatic re-render is the core of React's interactivity: you change the state, and the display follows, without you writing update steps. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

State differs from props in ownership: props come from a parent, state lives inside the component. A component's state should hold the smallest set of facts that describe its situation, and everything else should be derived from it when rendering, for the same reasons you met in component thinking. Keeping state minimal prevents contradictions, because there is only one copy of each fact, and the display is always computed from it. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a toggle component might hold a single boolean state, open or closed, and render its content only when open. Clicking the toggle flips the state, React re-renders, and the content appears or disappears. The developer never writes code to show or hide the element directly. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is storing data in state that could be derived from props or from other state, creating two copies that can disagree. Store the facts, derive the rest. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 9 — Rendering: from description to page

Rendering in React means turning a component's description into actual page elements, and re-rendering means doing it again when props or state change. The first render builds the page; later renders update it. React does not rebuild the whole real page on every render; it compares the new description with the previous one, as described in the virtual DOM section, and applies only the necessary changes to the real page. The word rendering therefore refers to producing the description and reconciling it, not to repainting everything. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

Understanding rendering helps you reason about performance and bugs. A component re-renders when its own state changes or when its parent passes new props, and its children may re-render as a result. That cascade is normal, but it means a component should render quickly and without side effects, such as fetching data or changing other state during rendering. Side effects belong in separate, controlled places that React provides for that purpose. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, typing in a search box changes the box component's state, which triggers a re-render, which produces a new description of the results list, which React reconciles into the page. The chain from keystroke to updated list is a series of renders, not a series of direct page edits. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is doing expensive work or causing side effects during rendering, which then runs on every render and slows the page or creates loops. Keep rendering pure: given the same props and state, it should produce the same description. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: How would you check your own work after applying the idea in this section?

Section 10 — One-way data flow

One-way data flow means data moves in a single, predictable direction through a React application: from parent components down to children through props, and from children back to parents through event announcements, not through direct data changes. The application's state lives in specific components, and changes to it flow down as new props, causing re-renders that update the display. There is no hidden channel by which a distant component can change another's data. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

Predictability is the payoff. When the screen shows something unexpected, you can trace the data backwards: which component rendered this, what props did it receive, and which component owns the state those props came from? That chain is always visible in the component tree, because data flow follows the tree. In a system where any component could change any other's data, tracing a bug would require searching the whole application. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a shopping basket total is computed from the basket state held by a parent, passed down to a summary component as a prop, and displayed there. The summary cannot change the total; only the parent, responding to add or remove events, can change the basket state, which then flows down again as a new total. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is trying to pass data sideways between siblings directly. Siblings communicate through their shared parent, which owns the shared state and passes it down to both. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 11 — Lists and keys in React

Rendering a list in React means turning a collection of data into a collection of components, usually by transforming each data item into a component element. Each item in such a list needs a key, a stable identifier that tells React which component corresponds to which data item when the list changes. Keys let React match old and new lists correctly, so that adding, removing, or reordering items updates the right components instead of confusing them. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

Keys matter most when a list changes. Without a stable key, React may reuse a component for a different item, carrying over its state incorrectly, such as showing one item's expanded state on another item after a sort. With a stable key, usually an identifier from the data, React tracks each item correctly across changes. The key is not displayed; it is bookkeeping for React's reconciliation, and it should be stable, unique among siblings, and derived from the data, not from position.

For example, a list of articles might render each article as a card with a key set to the article's identifier. When a new article is added at the top, React uses the keys to recognise the existing articles and adds only the new card, leaving the others untouched. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is using the item's index in the list as its key. Indices change when the list is sorted or filtered, which defeats the purpose of the key and can produce exactly the confusion keys exist to prevent. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 12 — Conditional rendering in React

Conditional rendering in React means that a component's output varies with its props or state, using ordinary JavaScript logic: conditions, variables, and short-circuit expressions inside the component function. Because a component is a function returning a description, it can return one description in one case and a different description in another, and React will update the page accordingly when the condition changes. There is no separate template language for conditions; JavaScript itself is the mechanism. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

This approach unifies the states you met in component thinking: loading, empty, error, and success are simply different return values of the same component, chosen by its current state. Writing them as branches of one function keeps the states together and makes it obvious when a state is missing, because the function's logic shows every case it handles and, by omission, every case it does not. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a data component might return a loading message while loading is true, an error message when an error exists, an empty message when the list is empty, and the list itself otherwise. Each branch is a complete description of that state. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is handling conditions by directly showing and hiding elements elsewhere in the code, instead of letting the component's return value express the condition. That splits the state logic across the application and makes it harder to see which states exist. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 13 — Events in React

Events in React are handled by passing functions as props, usually written as attributes on elements in JSX, such as an on-click handler. When the user interacts with the element, React calls the handler function, which typically changes state or announces an event to a parent component. The handler is ordinary JavaScript, so it can read state, compute values, and decide what to do, but it should not directly edit the page's elements, because React owns the display and will overwrite direct edits on the next render. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

React's event system normalises differences between browsers, so a handler written once works consistently, and it attaches handlers efficiently rather than attaching a separate listener to every element in the naive way. For a learner, the important idea is simpler: an event handler is a function that runs in response to a user action, and its job is to change state or announce news, not to manipulate the page directly. The page update follows from the state change, through re-rendering. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a button might carry an on-click handler that flips a boolean state, and the component's description might show different text depending on that state. The click changes state; the re-render changes the display. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is writing a handler that edits the page directly, such as changing an element's text, and then being puzzled when React reverts the edit. Change state, and let React change the page. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 14 — Controlled components and forms

A controlled component in React is a form element whose value is held in state and updated on every change, so that React's state is always the source of truth for what the input contains. The input's displayed value comes from state, and its change handler updates state, creating a loop: user types, handler updates state, re-render displays the new value. That loop gives the component full knowledge of the input at all times, which enables live validation, formatting, and character counts. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

Controlled components are the natural consequence of React's model applied to forms. If the page is a function of state, then an input's value should also be a function of state, not a separate fact living only in the page element. The alternative, uncontrolled components, where the value lives in the element and is read only when needed, exists and suits simple forms, but controlled components are the default recommendation for forms that need live behaviour. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, a controlled search input might hold its text in state, display that state as its value, and filter a list on every keystroke from the same state. The input, the state, and the filtered list can never disagree, because they all derive from one value. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is setting an input's value from state without providing a change handler, which makes the input appear frozen, because React resets it to the state value on every render. Value and handler go together. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: How would you check your own work after applying the idea in this section?

Section 15 — Composition in React

Composition in React means building components from other components, passing content through children or props, rather than building large, monolithic components. A layout component might accept children and render them inside a shared header and footer; a list component might accept an item component; a wrapper component might add behaviour around arbitrary content. Composition is React's primary reuse mechanism, and it is more flexible than trying to make one component configurable for every case. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

The children prop is central to composition: when you write content between a component's opening and closing tags in JSX, that content is passed to the component as its children, and the component decides where to render it. This lets a component own its structure while delegating its content, which is exactly the slot idea from component thinking, expressed in React's terms. Learning to design components around children, rather than around many specific props, produces flexible, reusable components. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a card component might render its children inside a styled box, so that one use supplies text, another supplies an image and a button, and both share the card's frame. The card does not need to know what its content is. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is creating a component with a prop for every possible piece of content, instead of accepting children. Many props for content is a sign that children would be simpler. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 16 — Thinking in React: breaking down a UI

Thinking in React is a design process that starts from a visual design and ends with a component structure. First, break the interface into components. Second, arrange them into a hierarchy, from the page down to the smallest pieces. Third, decide what data each component needs and where that data should live, identifying the minimal state. Fourth, decide which component owns each piece of state, and how changes flow up and down. That sequence, design, hierarchy, data, ownership, is a reliable way to start any React interface. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

The process matters because it separates decisions that are often tangled together. Deciding the component hierarchy before deciding state prevents state from being scattered, and deciding the minimal state before writing code prevents duplicated facts. Many React difficulties trace back to skipping a step: a hierarchy chosen without thought produces prop drilling, and state chosen without thought produces contradictions.

For example, given a product page design, you might identify a gallery, a details section, and a reviews list, then decide that the selected image state belongs in the gallery, while the basket state belongs higher, because both the details section and the header need it. Each state has one owner, chosen by who needs it. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is starting to code before breaking down the design, and then discovering that the component structure does not match the interface. Spend time on the breakdown; it is the design work, not a delay to it. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 17 — React and the DOM

React does not replace the browser's DOM; it manages it. The DOM remains the real, live representation of the page that the browser displays and that assistive technology reads. React's virtual DOM is an internal model used to decide how the real DOM should change, and React applies those changes through the same DOM interfaces that plain JavaScript uses. The result is an ordinary web page, with ordinary elements, that can be inspected in developer tools like any other page. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

This matters for accessibility and debugging. Because the final page is real HTML elements, semantic elements, labels, headings, and keyboard behaviour all work as they do in plain pages, and they remain the developer's responsibility. React does not automatically make a page accessible; it makes it easier to build accessible components consistently, because accessibility behaviour can be encapsulated in a component and reused. Inspecting a React page in developer tools shows the real elements React produced, which is the right place to debug display problems. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a React button component should still render a real button element, not a generic element with a click handler, so that keyboard users can focus and activate it. The component abstraction does not change the element's responsibilities. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is assuming that because React manages updates, the developer no longer needs to understand the DOM. The DOM is still the page, and understanding it is still essential for debugging and accessibility. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 18 — What React does not do

React, as a library, does not do everything a complete application needs. It does not provide routing between pages, it does not fetch data from a server by itself, it does not manage styles, and it does not supply a complete set of interface components. Those concerns are handled by additional libraries, by browser features, or by code you write, and choosing them is part of building a React application. Frameworks built on React bundle many of those choices together, but React itself remains focused on components and rendering. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

Knowing React's boundary prevents two misunderstandings: expecting React to solve a problem it does not address, and blaming React for a problem that belongs to another library. It also explains why React learning resources often mention other tools alongside React: the tools are companions, not parts of React, and they can be swapped without abandoning React itself. A learner should focus first on React's core ideas, components, props, state, and rendering, and treat the surrounding tools as later, separate topics. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, fetching a list of articles from a server is not a React feature; it is done with ordinary browser fetching, and the fetched data is then stored in state, which React renders. The fetching and the rendering are separate jobs, even though they appear together in an application. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is learning React and its ecosystem all at once, and confusing which idea belongs to which tool. Learn React's core first, then add one companion tool at a time. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 19 — React in a plain page: the concept

React can be introduced into a plain HTML page gradually, by adding a script and rendering a single component into one element on the page, while the rest of the page remains ordinary HTML. That gradual adoption is a deliberate feature: you do not need to rebuild a whole site to try React on one interactive section, such as a search box or a comment list. The React component manages its own part of the page, and the rest of the page is untouched. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

This idea is useful for learners, because it lets you compare React's approach with plain JavaScript on the same page, and for existing sites, because it lets them adopt React piece by piece. It also clarifies React's scope: React manages the part of the page you give it, through a root element, and it does not need to own the entire document. Larger applications give React the whole page, but that is a choice, not a requirement. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, a blog page written in plain HTML might add a React comment section, rendered into a single container element, while the article text, header, and footer remain plain HTML. The comment section is interactive in React's way; the rest of the page is unchanged. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is assuming React requires a complex build setup before it can be tried at all. A build setup is the usual path for large applications, but the concept of rendering into one element is the same at any scale. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: How would you check your own work after applying the idea in this section?

Section 20 — Build tools: why they appear with React

Build tools appear in React work because JSX and modern JavaScript need to be converted into code that browsers can run directly, and because applications are usually split across many files that need to be combined for delivery. A build tool reads the component files, converts JSX into JavaScript calls, combines the files, and produces the files that are actually sent to visitors. During development, it also provides a fast feedback loop, rebuilding when a file changes so the developer can see results quickly. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

For a concepts chapter, the important point is not which build tool to use, but why one exists at all: JSX is not understood by browsers directly, and a multi-file application needs assembling. Understanding that reason prevents the build tool from feeling like arbitrary complexity, and it explains why plain-page React examples, which load a converter in the browser, are slower and suited only to learning and experiments. Production React applications are built before they are served. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a project with twenty component files might be built into a small number of output files, with JSX converted and unused code removed, ready to be served to visitors. The source files remain the developer's working material; the built files are the delivered product. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is confusing the build tool with React itself, and thinking that a build error is a React error. Build tools, JSX conversion, and React's runtime are separate layers, and an error's message usually says which layer produced it. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 21 — Hooks: the concept

Hooks are React's mechanism for letting a function component use state and other React features. Before hooks, state and lifecycle behaviour were associated mainly with a different kind of component, and function components were simpler. Hooks changed that by giving function components a way to hold state, to run side effects such as fetching data, and to share logic between components, all while remaining ordinary functions. The name hook reflects the idea: the component hooks into React's features from inside a function. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

At concept level, the key idea is that hooks let a component remember things across renders and react to changes, without the component ceasing to be a function. A state hook, for example, gives the component a current value and a function to update it, and calling that function triggers a re-render with the new value. Other hooks handle effects, shared context, and performance, each following the same pattern: a function call inside the component that connects it to a React feature. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a counter component might use a state hook to hold its count, display the count, and update it when a button is clicked. The component remains a function returning a description; the hook supplies the memory that lets it change over time. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is thinking of hooks as a separate language to learn before components make sense. Hooks are best understood after components, props, and state are clear, because they are a mechanism for those ideas, not a replacement for them. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 22 — Effects: the concept

Effects are React's concept for work that happens outside rendering, such as fetching data, setting up a timer, or updating the page title. Rendering should be pure, producing a description from props and state without side effects, but real applications need side effects, and effects are the controlled place for them. An effect runs after rendering, when its dependencies change, and it can clean up after itself when the component is removed or before it runs again. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

The dependency idea is central: an effect declares which values it depends on, and React runs it when those values change, not on every render. That gives the developer control without manual bookkeeping. Cleanup is equally important: an effect that sets up a subscription or a timer should return a cleanup function that removes it, so that resources do not leak when the component disappears. Effects are therefore the answer to the lifecycle question in function components: setup, update, and cleanup, expressed as one concept. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a component that shows a document's title might use an effect to update the title whenever the document's name changes, and a component that subscribes to live updates might use an effect to subscribe on appearance and unsubscribe on removal. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is putting side-effect work directly in the render function, where it runs unpredictably and can cause loops. Side effects belong in effects, and rendering stays pure. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 23 — Context: the concept

Context is React's mechanism for passing data through the component tree without passing props through every intermediate component. A context is created with a default value, a provider component supplies a value at some level of the tree, and any descendant can read that value, however deep it sits, without the intermediates needing to know about it. Context is designed for data that many components need, such as the current theme, the logged-in user, or a language setting. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

Context solves the prop drilling problem discussed earlier, but it should not be the default for all data. Because context makes data flow invisible, passing through components without appearing in their props, it can make an application harder to trace if overused. The guideline is: use props for data that flows between a parent and its direct children, and use context for data that is genuinely global to a section of the tree, where prop passing would burden many unrelated intermediates. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a theme context might supply light or dark mode to every component in an application, so that a deeply nested button can read the theme without every intermediate component forwarding a theme prop. Changing the theme at the provider updates all readers together. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is putting frequently changing data, such as a fast-updating value, into context, causing many components to re-render on every change. Context suits relatively stable, widely needed values. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 24 — Unidirectional flow and debugging

Unidirectional data flow makes React applications easier to debug, because a bug's cause can be traced along a single direction. If a component displays the wrong value, check the props it received; if the props are wrong, check the parent that passed them; if the parent's state is wrong, check the event handler that changed it. Each step has one direction and one owner, so the search narrows quickly instead of wandering through the whole application. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

This debugging habit is worth practising deliberately. When something looks wrong, resist the urge to patch the display directly, and instead trace the data: where is this value stored, who changes it, and what props carry it here? The answer will usually reveal a state that was set incorrectly, a prop that was not passed, or a derivation that was computed from stale data. Fixing the data fixes the display everywhere it appears, while patching the display fixes only one symptom. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, if a list shows an old item after it was deleted, trace from the list component to its props to the parent's state: was the deletion handler actually updating the state, or was it only removing the element from the page? The trace distinguishes a state bug from a rendering bug. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is fixing a display bug by adding a special case in the rendering component, while the underlying state remains wrong. The special case will break again when the state is used elsewhere. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: How would you check your own work after applying the idea in this section?

Section 25 — React and accessibility

React does not automatically make an application accessible, but its component model makes accessibility easier to do consistently. When accessibility behaviour is built into a component, such as a button that is a real button element, a form field with an associated label, or a modal that manages focus, every use of that component inherits the behaviour. That reuse is the accessibility payoff of components, and it is why accessible component libraries are valuable. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

The developer's responsibilities remain the same as in plain HTML: use semantic elements, provide accessible names, manage focus for dialogs and dynamic content, and ensure that dynamic updates are announced where needed. React's dynamic updates deserve attention, because content that appears without a page reload may not be announced to screen reader users unless the component is designed to announce it. Test React interfaces with a keyboard and, where possible, with a screen reader, just as you would test a plain page. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a React tab component should be built from real tab semantics, with keyboard navigation and announced selection, not from generic elements with click handlers. The component encapsulates those behaviours, so every tab set on the site benefits. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is building React components from generic elements because JSX makes it easy to attach handlers to any element. Choose the semantic element first, then add behaviour. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 26 — React and performance: the concept

React's performance story is that it updates only what changed, through the virtual DOM comparison, so that most updates are cheap. That efficiency is usually sufficient, and premature optimisation in React is as unwise as elsewhere: build clearly, measure with realistic data, and optimise only the parts that measurement shows to be slow. Common optimisation concepts include avoiding unnecessary re-renders, memoising expensive calculations, and rendering only visible items in very long lists, but these are responses to measured problems, not starting points. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

A useful mental model is that rendering is cheap for small trees and expensive for very large ones, and that state changes near the top of the tree can cause many components to re-render. Keeping state as low as possible, so that a change affects only the components that need it, is therefore both a design principle and a performance habit. It is the same advice as storing data low in the tree, now with a performance reason added to the clarity reason. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a search input's state should live in the search component, not at the top of the application, so that typing re-renders the search area rather than the whole page. That placement is a design decision with a direct performance consequence. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is optimising every component before knowing whether it is slow, adding memoisation and complexity that obscures the code. Measure first, optimise the bottleneck, and keep the rest simple. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 27 — When React helps and when it does not

React helps most when an interface is highly interactive, with many pieces of state that must stay consistent, such as dashboards, editors, social feeds, and complex forms. In those cases, the declarative model and component reuse pay for React's learning cost and build complexity many times over. React helps least when a page is mostly static content, such as an article, a simple landing page, or a documentation site, where plain HTML and CSS would be simpler, faster, and easier to maintain. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

The decision should be based on interactivity and scale, not on fashion. A static site built with React carries a JavaScript dependency for content that could have been plain HTML, which hurts loading time and resilience: if the script fails, the content may not appear at all. A highly interactive application built without React carries the burden of manual DOM updating, which hurts correctness as the interface grows. Match the tool to the job's interactivity. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a blog article is best served as plain HTML, while a collaborative editor with live cursors, comments, and formatting is a natural React application. Most real projects sit between those extremes, and the choice deserves honest discussion. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is choosing React for every project because it is widely used, without asking whether the project's interactivity justifies it. Popularity is not a requirement. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 28 — React versus plain JavaScript

React versus plain JavaScript is a comparison of models, not of quality. Plain JavaScript gives you direct control over the page, with no build step and no library to learn, and it is excellent for small interactions: a toggle, a form validation, a simple list filter. React gives you a component model, declarative rendering, and automatic updating, which become valuable as interactions multiply and state grows. The two can coexist, with React managing one interactive section of an otherwise plain page. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

The learning path in this book reflects that comparison: plain JavaScript first, so that you understand the DOM, events, and state directly, and React second, so that you understand what problem it solves and what it abstracts away. A developer who learns React without plain JavaScript may struggle to debug it, because React's abstractions sit on top of the DOM, and its errors often point back to DOM concepts. A developer who knows both can choose the simpler tool for each job. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a page with a single dropdown menu does not need React, while a page with a filterable, sortable, paginated table, a shopping basket, and live notifications probably does. The number of interacting states is the deciding factor. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is rewriting a working plain JavaScript page in React for no reason other than to use React. A rewrite should solve a real problem, such as unmanageable state, not merely change the tool. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 29 — Learning React after the fundamentals

Learning React after the fundamentals means carrying forward everything from earlier chapters: HTML semantics, CSS layout, JavaScript functions and objects, DOM events, and component thinking. React does not replace those skills; it organises them. A React component still renders semantic HTML, still needs CSS for its appearance, still uses JavaScript logic for its behaviour, and still benefits from the component design habits of small jobs, clear APIs, and explicit states. Students who rush to React before those fundamentals often find React confusing, not because React is obscure, but because it assumes the fundamentals. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

The practical implication is to practise React on interfaces you already understand in plain form. Rebuild a component you built in plain JavaScript, such as a tab set or a card list, as a React component, and compare the two versions. The comparison will show you exactly what React changes: the description replaces the update steps, props replace manual data passing, and state replaces scattered variables. That comparison is the fastest route to genuine understanding. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, rebuild a simple counter first in plain JavaScript, with a variable and a render function, and then as a React component with state. The two versions solve the same problem, and their differences are React's contribution, visible in miniature. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is treating React as a shortcut that bypasses the fundamentals, and then being unable to debug a React problem that is really a JavaScript or DOM problem. Fundamentals first, framework second, remains the order. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: How would you check your own work after applying the idea in this section?

Section 30 — A first React mental model

A first mental model for React can be stated in one paragraph, and it is worth memorising: an application is a tree of components; each component is a function that receives props and may hold state; each component returns a description of what it should display, written in JSX; React turns those descriptions into the real page, and when props or state change, React re-renders the affected components and updates only the changed parts of the page. Events flow up through handlers, data flows down through props, and the screen is always a function of the current props and state. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

That model, simple as it sounds, explains most of what a beginner meets in React. A component that does not update is usually a state that was not changed correctly. A component that shows the wrong data usually received the wrong props. A list that confuses its items usually lacks stable keys. Returning to the model when confused, rather than guessing at a fix, will resolve most early problems, because the model states where each kind of bug must live. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, apply the model to a todo list: the list component holds the items in state, renders an item component per item with a key, and each item announces a toggle event that updates the state, causing a re-render that shows the item as done. Every part of the application fits the model. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is memorising React's syntax without the model, so that each new feature feels unrelated. Learn the model first, and syntax becomes a way of expressing it. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 31 — Common React misconceptions

Several misconceptions recur among React beginners, and naming them prevents them. First, React is not a separate language; it is JavaScript plus JSX and a component model. Second, JSX is not HTML; it is a syntax that describes elements and follows JavaScript rules in places. Third, the virtual DOM is not a page the user sees; it is an internal model for computing updates. Fourth, state changes do not update the page instantly by magic; they trigger a re-render, which React reconciles into the page. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

A fifth misconception is that React components must be large or complex to be real. Small components are the norm, and a component that renders a single button is a perfectly good component. A sixth is that React replaces CSS or HTML knowledge; it does not, because components still render HTML elements styled by CSS. Clearing these misconceptions early saves a great deal of confusion, because each one, believed, leads to a different kind of error. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, believing JSX is HTML leads to confusion over attribute names, while believing state updates the page directly leads to code that tries to read the updated page immediately after changing state, before React has re-rendered. Both errors disappear once the model is clear. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is holding onto a misconception because an early example seemed to support it. When an example contradicts your model, trust the model and re-examine the example. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 32 — React and teamwork

React helps teamwork for the same reasons component thinking does: it provides a unit of work, the component, with a clear interface of props and events, that can be assigned, reviewed, and tested independently. A team can agree on a component's API before building it, build components in parallel, and compose them into pages with confidence that they will fit. React's one-way data flow also makes code review easier, because a reviewer can trace data through the tree without hunting for hidden mutations. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

Teamwork in React also benefits from shared conventions: how components are named, where state lives, how data is fetched, and how components are documented. Those conventions are not part of React itself, but teams adopt them to keep a React codebase coherent as it grows. A new team member who learns the conventions can contribute quickly, because the codebase follows predictable patterns even though its components are many. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a team building a dashboard might assign the chart component, the table component, and the filter component to different developers, agreeing first on the props each accepts and the events each announces. The components are then built independently and composed into the dashboard page. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is letting each developer invent their own state patterns, so that the same kind of data is managed differently in different components. Agree on patterns early, and review for consistency. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 33 — From concepts to code: what comes next

From concepts to code, the next step is to write small React components and run them, starting with the simplest possible component and adding one idea at a time: first a component that renders fixed content, then one that accepts props, then one that holds state, then one that renders a list, then one that handles an event. Each step should be built, run, and tested before the next is added, so that any failure can be attributed to the newest idea. That incremental path mirrors how this chapter introduced the concepts, and it is the fastest way to turn understanding into skill. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

Later chapters will take up the practical side: setting up a React project, writing components in files, using a build tool, fetching data, and building a complete small application. Those chapters assume the concepts in this chapter, and they will move faster because of it. If a later practical step confuses you, return to the concept here that it implements: the practical step is almost always one of these ideas, made concrete in code. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a first practical exercise might be a greeting component that accepts a name as a prop, then a counter component that holds a number in state, then a list component that renders cards from data with keys. Those three exercises cover props, state, lists, and keys, which are most of React's core. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is jumping straight to a large React application tutorial without practising the small pieces, and then being unable to explain or fix the application. Small pieces first, composition second. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 34 — React and the wider ecosystem

React sits at the centre of a wide ecosystem of libraries and tools: routers for navigation between views, data-fetching libraries, form libraries, testing libraries, and frameworks that bundle React with routing, building, and server features. That ecosystem is a strength, because it lets a project choose the best tool for each job, and a weakness for beginners, because it presents many choices before the core is understood. The wise approach is to learn React's core first, then add ecosystem tools one at a time, each to solve a specific problem you have actually met. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

Frameworks built on React deserve a special note: they provide an opinionated starting point, with routing, building, and data handling already decided, which can accelerate a large project considerably. They are not React itself, and learning one before React's core can obscure which ideas belong to React and which belong to the framework. Learn the core, build a small application with it, and then evaluate frameworks from a position of understanding, not of dependence. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, a project that needs multiple pages might add a router library, while a project that needs complex forms might add a form library. Each addition should follow a need, not precede it, so that the project's dependencies remain justified and understood. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is installing many ecosystem libraries at the start of a project, before knowing which problems they solve. Start with React alone, and add tools as needs arise. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: How would you check your own work after applying the idea in this section?

Section 35 — Chapter 29 in one paragraph

This chapter has introduced React at concept level: a library for building interfaces from components, where each component is a function receiving props and possibly holding state, returning a JSX description of what it should display, and where React keeps the real page in sync with those descriptions through the virtual DOM and reconciliation. You have seen one-way data flow, lists and keys, conditional rendering, events, controlled components, composition, hooks and effects at concept level, and context, and you have seen when React helps and when plain JavaScript is the better choice. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

The through-line is declarative thinking: describe what the interface should be for a given set of data, and let React work out how to update the page when the data changes. That shift, from editing the page step by step to describing the desired result, is the heart of React, and it is also the heart of modern component-based interface development. The details of syntax and tooling, which later chapters will cover, are expressions of these concepts, not replacements for them. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a good final test of this chapter is to explain, without code, how a search box, a list, and a detail view would work as React components: what state each holds, what props each receives, and what events each announces. If you can explain that design, you understand React's concepts, whatever the syntax. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is ending a chapter like this with an opinion but no practice. Sketch the search, list, and detail design on paper, naming its components, props, state, and events, before moving on. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 36 — JSX expressions and logic

JSX expressions are JavaScript values inserted into markup inside curly braces, and they are how a component's description varies with data. Inside braces you can write a variable, a calculation, a function call, or a conditional expression, and React will insert the result into the output. This is not a separate template language with its own rules; it is JavaScript, evaluated in the component function, which means all of your JavaScript knowledge applies inside the braces. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

The power of expressions is that they unify logic and markup. A component does not need one language for structure and another for logic; it uses JavaScript for logic and JSX for structure, with braces as the bridge. Conditions can choose between descriptions, lists can be transformed into component elements, and values can be formatted before display, all in the same function. Keeping expressions simple, moving complex logic into variables before the return statement, keeps the markup readable. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a component might compute a greeting string from a name and a time of day, store it in a variable, and insert it with braces into a heading. The heading's structure is visible in JSX; the greeting's logic is visible in the variable's computation. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is putting long, complicated logic directly inside braces, making the markup hard to read. Compute first, then insert the result. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 37 — Fragments: grouping without a wrapper

A fragment is React's way of grouping several elements together without adding an extra wrapper element to the page. Normally a component returns a single root description, but sometimes the design calls for two sibling elements, such as two table cells or two list items, with no sensible wrapper between them. A fragment groups them for React's purposes while producing no element of its own in the real page. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

Fragments matter because extra wrapper elements can break layout or semantics: a wrapper div inside a table row is invalid HTML, and a wrapper around flex items changes the layout. Fragments avoid those problems by being invisible in the output. They are a small feature, but they show React's attention to producing correct, clean HTML: the component model should not force you to add elements the design does not need. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a component that renders two cells of a table row might return a fragment containing both cells, so the row contains exactly the cells and nothing else. The fragment is present in the component code and absent from the page, which is exactly right. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is wrapping everything in a div by habit, even when the wrapper harms layout or semantics. When a component needs to return siblings, reach for a fragment first. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 38 — Styling React components: the concept

Styling React components uses the same CSS as plain pages, and the choice of how to organise it is separate from React itself. A component's styles may live in a stylesheet imported alongside the component, in utility classes applied in JSX, or in a styling library, but in every case the styles target the HTML elements the component renders. React does not invent a new styling language; it renders elements, and CSS styles those elements as it always has. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

The component model does, however, change how styles are organised: because a component is a unit, its styles are often kept near it, so that changing the component means changing its styles in the same place. Whether that closeness is achieved with a stylesheet per component, with scoped styles, or with utilities is a project decision, and different projects choose differently. The concept to carry forward is that React components and CSS remain separate layers, even when their files sit side by side. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a card component might import a stylesheet that defines its layout and colours, and render elements with the classes from that stylesheet. The component function describes structure; the stylesheet describes appearance; neither does the other's job. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is writing styles inline for everything in React, because JSX makes inline styles easy to reach for. Inline styles are hard to reuse, hard to override, and limited in what they can express, so prefer stylesheets or utilities for most styling. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 39 — Default props and optional data

Default props are values a component uses when its parent does not supply a particular prop, and they make components easier to use by reducing the number of props a common case must pass. A button component might default its variant to a standard style, so that a simple use needs only a label, while a special use can pass a different variant explicitly. Defaults express the common case, and explicit props express the exception. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

Defaults should be chosen carefully, because they become the component's assumed behaviour. A good default is the value most uses would want, and it should never hide a required piece of information: a card without a title is not improved by a default title, because the title is essential content, not a stylistic choice. Distinguish required props, which the component cannot meaningfully render without, from optional props, which have sensible defaults. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, an avatar component might default its size to a medium value, so that most uses pass only an image, while a large profile display passes an explicit size. The default saves repetition without hiding anything essential. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is giving every prop a default, including props that carry essential content, which allows a component to render misleading placeholder content when its parent forgets to pass real data. Defaults are for presentation choices, not for content. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: How would you check your own work after applying the idea in this section?

Section 40 — Prop drilling in React

Prop drilling in React is the pattern where a value is passed through several intermediate components that do not use it, merely to reach a descendant that does. It arises naturally from one-way data flow, and in small doses it is harmless: a few intermediates forwarding a prop is clear and explicit. When the chain grows long, however, the intermediates become harder to understand, because they carry props unrelated to their own jobs, and changing the value's path requires editing every link in the chain. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

Prop drilling is a signal, not a failure. It tells you that the data's owner and its consumer are far apart in the tree, and that either the tree should be rearranged, the state should live lower, or a mechanism such as context should be considered. Which response is right depends on the case: sometimes moving the state down is enough, sometimes the data is genuinely global and context fits, and sometimes a short drilling chain is simply the clearest option and should be left alone. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a user name passed from a page component through a layout component and a header component to an avatar component is a short drilling chain. If the chain grew to six components, the design would deserve revisiting. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is introducing context to eliminate every instance of drilling, including short, clear chains. Explicit props are easier to trace than invisible context, so prefer them where the chain is short. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 41 — Lifting state up in React

Lifting state up in React means moving state from a child component to the nearest shared parent of all the components that need it. When two siblings must stay in sync, such as a tab button and its panel, or a filter control and its results list, neither sibling can own the state alone, because the other would not see changes. The parent owns the state, passes it down as props, and receives change announcements as events, keeping a single source of truth. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

This pattern is the practical application of one-way data flow to shared state, and it is one of the most frequently used patterns in React work. It also explains why state ownership is a design decision, not an accident: the component that owns a piece of state should be the lowest common ancestor of all components that read or change it. Placing state higher than necessary causes unnecessary re-renders and prop drilling; placing it lower than necessary causes synchronisation bugs. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a tab set component might own the selected tab state, passing the selection to each tab button and rendering the matching panel, so that clicking a tab updates both the button's appearance and the panel together, from one state change. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is keeping state in a child and trying to share it by other means, such as reading the child's display. State belongs in the shared parent, and the display follows from it. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 42 — Reusable components in React

Reusable components in React are components designed to serve many uses, with a clear API, sensible defaults, and no assumptions about their surroundings. A reusable button does not assume it lives in a form or a header; it accepts a label, a variant, and a click handler, and it works anywhere those are supplied. Reusability is earned by generality: the component does its job and nothing else, and it leaves decisions that vary between uses to its props. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

Designing for reuse requires resisting the temptation to specialise. A card component that hard-codes a particular site's header, footer, and colours is not reusable, even if it is used twice on that site. A card component that accepts children for its content and props for its variant can be reused across the site and across projects. The test of reusability is whether the component can be used in a context its author did not anticipate, without modification. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, a well-designed modal component can serve a confirmation dialog, a form, and an image viewer, because it owns only the frame and focus behaviour, and accepts its content as children. Its reusability comes from what it does not assume. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is making a component reusable by adding a prop for every conceivable variation, until its API is harder to learn than writing the component from scratch. Reusable means general for common cases, not configurable for every case. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 43 — React component files and organisation

In a React project, components are usually organised one per file, with the file named after the component, and related components grouped in folders by feature or by type. That organisation mirrors component thinking: a developer looking for the card component finds one file containing it, and a folder's contents reveal the components that make up a feature. Larger components may have their styles or tests alongside them, keeping everything about the component in one place. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

File organisation is a convention, not a React requirement, but conventions matter in team projects, because they let any developer find any component quickly. The two common schemes, grouping by feature and grouping by type, both work; what matters is consistency within a project, so that a component's location is predictable. As a project grows, feature grouping often wins, because it keeps everything about one part of the product together, even when that part uses several kinds of files. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a shop feature folder might contain the product card, the product list, and the product details components, together with their styles, while a shared folder contains the button and input components used by every feature. The structure tells the story of the product. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is putting all components in one flat folder, which becomes unsearchable as the project grows, or organising by file type so that a component's parts are scattered. Organise by component and feature, and keep the structure shallow. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 44 — Immutability: the concept

Immutability in React means treating state as values that are replaced, not modified in place. When a list in state needs a new item, you create a new list containing the old items plus the new one, rather than appending to the existing list. When an object in state needs a changed field, you create a new object with the changed field, rather than editing the existing object. React relies on this pattern to detect changes efficiently: comparing whether a value is a new object is fast, while checking whether an existing object was edited is not. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

Immutability also makes reasoning easier, because a value, once created, never changes unexpectedly. A component that received a list as a prop can trust that the list will not be altered behind its back, and a previous state value remains available for comparison or for undo behaviour. The habit takes practice for developers used to editing values directly, but it is central to React's model, and most React bugs involving stale displays trace back to a mutation that React did not detect. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, adding an item to a todo list in state should produce a new array, and React, seeing a new array, re-renders the list. Mutating the existing array in place may leave React unaware that anything changed, so the page does not update. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is mutating state directly and then wondering why the page did not update. Replace state values; do not edit them. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: How would you check your own work after applying the idea in this section?

Section 45 — Rendering lists from data

Rendering lists from data is the pattern where a component transforms an array of data into an array of component elements, one per item, and React renders them as a list. The transformation uses ordinary JavaScript, mapping each data item to a component element with a stable key, and the result is inserted into the component's output. That pattern connects data and display directly: the list on the page is always the list in the data, because it is computed from it on every render. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

This pattern's simplicity is its strength. Filtering, sorting, and searching a list become operations on data, not operations on page elements: filter the array, and the rendered list follows. It also unifies empty and non-empty lists, because mapping an empty array produces no elements, and the component can then render an empty message instead. The list component's job is to manage the collection; the item component's job is to render one item. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, a list of products might map each product to a product card component, keyed by the product's identifier, so that the page shows exactly the products in the data, in the data's order, with no extra bookkeeping. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is maintaining the page list separately from the data list, adding and removing elements by hand. Keep one list, the data, and derive the page from it. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: Describe a situation from a real project where the idea in this section would matter.

Section 46 — React and the wider JavaScript world

React exists within the wider JavaScript world, and its concepts connect to ideas you already know: components are functions, props are function arguments in object form, state is a variable that triggers re-rendering when replaced, and JSX expressions are JavaScript expressions. That continuity is reassuring: React does not ask you to forget JavaScript, but to use it in a particular structure, with a library managing the connection between your functions and the page. In plain terms, this idea exists because real projects grow. A page that starts with a handful of styles can end up with hundreds, and without a clear approach the stylesheet becomes hard to read, hard to change, and easy to break by accident. The idea in this section gives you a rule you can apply consistently, so that a change in one place does not produce a surprise somewhere else on the site.

React also connects to the wider web platform: it renders real HTML elements, it uses browser events, it works with CSS, and it can be combined with other libraries for routing, data, and forms. Understanding React as a layer on top of JavaScript and the web platform, rather than as a separate world, helps you debug it, because its problems are often JavaScript or DOM problems wearing React clothing. It also helps you learn the next tool, because the underlying platform remains the same. In practice, start small and observe the result before adding more. Build one component or one page section, apply the idea there, open the page in a browser, and resize the window to see how it behaves. Small, observable steps make it obvious which change caused which effect, and that feedback loop is how good front-end judgement is formed.

For example, a React event handler is a JavaScript function, a React list is a JavaScript array transformation, and a React component's output is a description of HTML elements. None of those ideas is new; React's contribution is how they are combined and managed. A common mistake is to copy a solution without understanding what each part does, then to be stuck when it needs adjusting. Avoid that by reading the example line by line and asking what would happen if each part were removed. The lines you cannot explain are the lines most likely to cause trouble later.

A common mistake is treating React as a closed system and avoiding the underlying JavaScript and DOM knowledge it builds on. The platform underneath is still there, and it still matters. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: Explain, in your own words, the main idea of this section and give one example.

Section 47 — Putting React concepts together

Putting React concepts together means seeing how props, state, rendering, events, and composition combine in a single small application. Consider a simple notes application: a page component holds the notes in state, renders a form component for adding notes, and renders a list component that renders a note component per note. Adding a note is an event from the form, handled by the page, which replaces its state with a new list, causing a re-render that shows the new note. Deleting a note follows the same cycle in reverse. Think of this as a working habit rather than a piece of trivia. You will use it on almost every page you build, and the benefit appears gradually: files stay shorter, decisions become easier to explain to a teammate, and fixing a visual bug takes minutes instead of an afternoon of hunting through unrelated rules.

That cycle, event, state change, re-render, updated page, is React's heartbeat, and every React application, however large, is composed of such cycles. Larger applications have more components, more state, and more cycles, but the pattern does not change: data flows down, events flow up, and the screen is a function of props and state. Holding that pattern in mind while reading larger codebases will let you orient yourself quickly, because you will know what kind of thing to look for at each step. When you apply this idea, keep the surrounding code in mind. A front-end page is a system: markup, styles, and behaviour interact, and a choice that looks good in isolation can create a problem elsewhere, such as overflowing content on a narrow screen or a colour that fails a contrast check. Test the whole page, not just the fragment you edited.

For example, trace any feature of a React application you use and ask: what state changed, which component owned it, what event caused the change, and which components re-rendered as a result? Answering those questions for a real feature is a complete React lesson in itself. Another frequent mistake is to mix approaches in the same file without a reason: part of the page follows one convention and part follows another. That inconsistency makes the code harder to scan and harder to maintain, because a reader cannot predict which convention applies where. Pick one approach for a given job and use it consistently.

A common mistake is learning each React concept in isolation and never tracing a full cycle through a real feature. Concepts combine into cycles, and cycles are what applications are made of. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: When would you use the idea in this section, and when would you choose a different approach?

Section 48 — Debugging React by thinking in components

Debugging React by thinking in components means locating a bug by asking which component is responsible, rather than by guessing at the page as a whole. If a value is wrong, find the component that renders it, check its props, and trace those props to their owner. If an interaction does nothing, find the component that should handle the event, check that the handler is passed and that it changes state. If a list confuses its items, check its keys. Each symptom points to a component-level cause, and the component tree gives you a map for the search. The reason this matters for a beginner is that early choices compound. If you adopt a messy approach on a small practice page, the same approach will feel natural on a larger project, where its cost is much higher. Learning the disciplined version now saves you from having to unlearn a habit later, when a real deadline is involved.

Developer tools support this approach: React's tools show the component tree, the props and state of each component, and the hierarchy that data flows through. Inspecting the tree is often faster than reading code, because it shows the application's actual state at the moment of the bug, not the state the code was intended to produce. Combine the tools with the mental model, and most React bugs become systematic searches rather than mysteries. A practical test is to change one thing deliberately. Alter a value, remove a class, or rename something, then refresh and watch what breaks. That experiment teaches you what actually depends on the idea, which is far more useful than memorising a definition. Undo the change afterwards and confirm the page returns to normal.

For example, a button that does nothing might have a handler that was never passed, a handler that changes the wrong state, or a state change that was mutated instead of replaced. Each possibility lives in a different component, and the tree shows you which one to inspect first. Watch out for overuse. A technique that helps in moderation can hurt when applied everywhere: too many classes, too many wrappers, or too many overrides all add weight and confusion. If a page feels complicated, look for the simplest version that still meets the design, and prefer that version.

A common mistake is debugging by editing code at random until the symptom disappears, which often introduces a new bug while leaving the original cause in place. Locate first, then fix. Keep a small practice file where you try each idea in isolation. A tiny page with a single component is a better laboratory than a large project, because there is nothing else to confuse the result. Once the idea works there, carry it into a real page with confidence.

Check: What goes wrong if you ignore the advice in this section? Give a concrete example.

Section 49 — What to build first with React

What to build first with React should be small, familiar, and interactive: a counter, a toggle, a todo list, a filterable list, or a tab set you have already built in plain JavaScript. Familiarity matters, because it lets you focus on React's model rather than on the feature's design, and comparison matters, because rebuilding something you understand shows you exactly what React changes. Each small project should exercise one new idea, and each should be finished and tested before the next begins. A useful way to judge this idea is to ask what happens when the design changes. Clients and designers change colours, spacing, and layouts often. An approach that survives those changes without a rewrite is a good one; an approach that forces you to edit dozens of files for one small change is a warning sign.

A good first sequence is: a component that renders fixed content, then the same component with props, then a counter with state, then a list with keys, then a form with a controlled input, then a small application composing several components. That sequence covers React's core in the order this chapter introduced it, and each step is small enough to debug when it fails. Resist the temptation to start with a large tutorial application; its size will hide the concepts this chapter worked to make clear. Do not adopt this idea blindly on every element. Ask whether it earns its place in this particular case: does it make the code clearer, the page faster, or the design more consistent? If the answer is no, plain hand-written code may be the better choice. Good developers choose tools for a reason they can state.

For example, a todo list is an ideal first application because it uses state for the items, props for each item, keys for the list, events for adding and toggling, and conditional rendering for the empty state. It is small, but it is complete. A subtler mistake is to optimise for the first screen you test and forget the rest. Check a narrow phone width, a large desktop width, and a zoomed-in view. Many front-end bugs only appear at an extreme, and catching them early is much cheaper than explaining them to a user who has already encountered them.

A common mistake is building a first React project that is too large, and then attributing its difficulties to React rather than to its size. Small and finished beats large and abandoned. To check your own work, open the page, inspect the relevant element in developer tools, and confirm that the styles you expect are actually applied rather than overridden or ignored. Then change the browser width, reload, and confirm nothing has broken. Write down anything surprising; those notes become your personal checklist for the next project.

Check: How would you check your own work after applying the idea in this section?

Section 50 — Chapter 29 in one paragraph, revisited

This final section returns to the chapter's central claim, because it is worth restating after the details: React is a way of describing interfaces as components, where data flows down through props, events flow up through handlers, state lives in the component that owns it, and the screen is always a function of props and state. JSX lets those descriptions look like the structure they produce, the virtual DOM lets React update the real page efficiently, and hooks, effects, and context are mechanisms that extend the same model to state, side effects, and shared data. This idea also affects how other people read your work. A teammate, a future version of yourself, or a reviewer judging a portfolio project should be able to open your code and understand the intention quickly. Clear, consistent choices communicate professionalism even before anyone runs the page.

If you remember nothing else from this chapter, remember that cycle: an event changes state, state triggers a re-render, and the re-render updates the page. Every other idea in the chapter, from keys to fragments to controlled components, is a refinement of that cycle for a particular situation. Later chapters will make the cycle concrete in code, but the cycle itself, understood now, will make that code intelligible rather than mysterious. Remember accessibility while you work. Visual changes are not only about appearance; they affect whether text remains readable, whether interactive elements remain reachable by keyboard, and whether a screen reader still announces content in a sensible order. Check those things as you go, not as an afterthought at the end.

For example, explain the cycle to a friend using a todo list, a search box, or any interface you know well, without mentioning any syntax. If the explanation is clear, the concepts are yours; syntax is then a matter of learning how to write down what you already understand. Finally, do not confuse looking finished with being finished. A page can look correct in one browser and fail in another, or look correct with short sample text and break with a long real heading. Test with realistic content, realistic text lengths, and at least one other browser before you call the work done.

A common mistake is finishing a concepts chapter without testing the concepts against a real design. Sketch one interface, name its components, and trace one event through its cycle before you move on. A good self-check is to explain the idea aloud in one or two sentences without looking at this section. If you can do that and give a correct example, you understand it well enough to use it. If you cannot, re-read the example and try building a tiny version from scratch before moving on.

Check: Describe a situation from a real project where the idea in this section would matter.

Practical task

On paper, design a small React application for a searchable list of articles: draw its component tree, name each component, list the props each receives, name the state each holds and who owns it, and trace what happens, step by step, when a user types a search term. Do not write code for this task; the design, with its data flow and event flow clearly labelled, is the deliverable, and it should be complete enough that another learner could implement it from your sketch.

Chapter questions

Explain declarative UI in your own words, and contrast it with directly editing page elements step by step.

What is the difference between props and state in React, and who owns each?

Why does a list in React need stable keys, and why is an item's position a poor key?

A React input appears frozen: the user types but nothing changes. What is the most likely cause?

When would plain JavaScript be a better choice than React for a page, and when would React be the better choice?