Web Development 4

Components need data. A profile card needs a user's name and photo. A counter needs a number that changes when you click a button. React handles data in two distinct ways: props (data passed into a component from its parent) and state (data managed inside a component that can change over time). Understanding the difference is the single most important concept in React.

Props: Data Flowing Down

Props are how parent components pass data to child components. They work like HTML attributes. When you write <ProfileCard name="Kiarra" role="Creator" />, you're passing two props: name and role. Inside the ProfileCard component, you receive them as an object parameter and use them in your JSX.

Props are read-only. A child component should never modify the props it receives. This one-way data flow is a core React principle. Data flows down from parent to child, never the other direction. If a child needs to communicate something back up to its parent, the parent passes a function as a prop, and the child calls that function.

You can pass anything as a prop: strings, numbers, arrays, objects, functions, even other components. This flexibility is what makes components truly reusable. A Button component that accepts an onClick prop and a label prop can be used for "Submit," "Cancel," "Delete," or anything else without changing its internal code.

The useState Hook

State is data that lives inside a component and can change in response to user actions. The useState hook is how you create state in function components. It returns an array with two items: the current value and a function to update it.

When you call const [count, setCount] = useState(0), you're creating a state variable called count with an initial value of 0, and a setter function called setCount. When you call setCount(count + 1), React re-renders the component with the new value. You never modify state directly. Always use the setter.

This re-rendering behavior is the heart of React. When state changes, the component function runs again, JSX is recalculated, and React efficiently updates only the parts of the DOM that actually changed. You don't write any DOM manipulation code. You just describe what the UI should look like for the current state, and React handles the transitions.

Lifting State Up

Sometimes two sibling components need to share the same data. For example, a search input and a results list both need access to the search query. Since props only flow downward, the solution is to "lift" the shared state up to the nearest common parent.

The parent component owns the state and passes it down to both children as props. It also passes a setter function down to the child that needs to update the state. When that child calls the setter, the parent re-renders, which re-renders both children with the new data. This pattern feels indirect at first, but it keeps data flow predictable and debuggable.

Controlled Components

In plain HTML, form inputs (text fields, checkboxes, selects) manage their own internal state. The browser tracks what the user has typed. In React, you typically take control of this by making the input's value a piece of React state. This is called a controlled component.

For a text input, you set its value prop to a state variable and its onChange prop to a function that updates that state variable. Every keystroke triggers the onChange handler, which updates state, which re-renders the input with the new value. It sounds circular, but it gives you total control: you can validate input in real time, format it, prevent certain characters, or sync it with other parts of your UI.

Think of props as arguments to a function. Think of state as variables inside a function. Props come from outside; state is managed inside. When state changes, the component re-renders.

A real application has multiple pages: a home page, an about page, a portfolio, a contact form. In a traditional website, each page is a separate HTML file and clicking a link triggers a full page reload from the server. In a React application, you build a Single-Page Application (SPA) where navigation happens entirely in the browser, with no reloads, making transitions instant and smooth.

React Router

React Router is the standard routing library for React. Install it with npm install react-router-dom. It provides components that map URL paths to React components, so when the user navigates to /about, React Router renders your About component, and when they go to /portfolio, it renders your Portfolio component, all without a page reload.

The setup involves wrapping your app in a BrowserRouter component, defining your routes with Routes and Route components, and using Link components instead of regular anchor tags for navigation. The Link component prevents the default browser navigation and lets React Router handle the URL change in JavaScript.

A basic setup looks like this: BrowserRouter wraps everything at the top level (usually in main.jsx). Inside your App component, you define Routes containing individual Route elements, each mapping a path to an element (your component). Your navigation uses Link components with to props instead of anchor tags with href attributes.

SPA Navigation

When a user clicks a Link in your React app, several things happen behind the scenes. React Router intercepts the click, updates the browser's URL bar (using the History API), and tells React to render the component associated with the new path. The browser's back and forward buttons work correctly because React Router syncs with the browser's history stack.

This is dramatically faster than traditional navigation because the browser never makes a round trip to the server. The JavaScript bundle containing all your components is already loaded. Switching pages is just swapping which component is rendered, which happens in milliseconds.

One practical consideration: if you want a navigation bar that appears on every page, put it outside the Routes component but inside the BrowserRouter. This way the nav renders on every route without being included in each page component individually.

Dynamic Routes

Many applications have pages that follow a pattern. A blog might have /posts/1, /posts/2, /posts/3 and so on. You don't want to hardcode a route for every single post. Instead, you define a dynamic route with a URL parameter: /posts/:id. The colon indicates a variable segment.

Inside the component that renders for that route, you use the useParams hook to access the parameter. If the user navigates to /posts/42, calling useParams() gives you { id: "42" }. You then use that ID to fetch the right data or display the right content. This pattern is used everywhere: user profiles (/users/:username), product pages (/products/:productId), and project details (/projects/:slug).

Protected Routes

Some pages should only be accessible to logged-in users. A dashboard, account settings, or admin panel shouldn't be visible to random visitors. Protected routes check whether the user is authenticated before rendering the component. If they're not authenticated, you redirect them to a login page.

The common pattern is to create a wrapper component (often called ProtectedRoute) that checks authentication status. If authenticated, it renders the child component. If not, it uses React Router's Navigate component to redirect to /login. You wrap your protected routes with this component in your route definitions.

This module ties everything together. You'll build a real, functional creator dashboard that fetches data from an API, displays it in organized components, includes a working form, and deploys live to Cloudflare Pages. This is the kind of project you'd put in a portfolio or adapt for your own creator business.

Fetching Data from APIs

Most real applications don't have their data hardcoded. They fetch it from APIs (Application Programming Interfaces), which are endpoints that return data, usually in JSON format. React provides the useEffect hook for running side effects like data fetching when a component mounts.

The pattern looks like this: you declare a state variable for your data (starting as an empty array or null), a loading state (boolean), and optionally an error state. Inside a useEffect with an empty dependency array (so it runs once on mount), you call fetch() with the API URL, convert the response to JSON, and set your data state with the result.

While data is loading, you render a loading indicator. If an error occurs, you render an error message. Once data arrives, you map over it to render your components. This loading/error/success pattern is used in virtually every React application. Get comfortable with it because you'll write it dozens of times.

For this course, we'll use free public APIs to simulate real data. The JSONPlaceholder API provides fake posts, users, and comments that are perfect for practice. In a real creator dashboard, you'd replace these with your own API endpoints.

Displaying Content in Components

Once you have data, you need to display it. The React way is to map() over your data array and render a component for each item. Each item component receives the data as props. Remember to add a unique key prop to each item in the list. React uses keys to efficiently update the DOM when items change, are added, or removed.

A creator dashboard might display content cards showing your posts, their view counts, publish dates, and status (published/draft). Each card is a component. The dashboard page fetches the data and maps over it, passing each post's data to a Card component. This separation of concerns keeps your code organized as the application grows.

Forms That Submit Data

You built a contact form in Module 2. Now let's go further. In a real dashboard, forms don't just display data locally. They send it to a server. The process uses fetch() with the POST method instead of GET.

When the user submits the form, you prevent the default form submission with e.preventDefault(), construct a request body from your state, and send it with fetch(url, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(formData) }). You handle the response, show a success message, and clear the form.

Good form UX includes disabling the submit button while the request is in flight, showing a loading state, handling errors gracefully (network failures, validation errors from the server), and providing clear feedback on success. These details separate a polished application from a prototype.

Deploying to Cloudflare Pages

Deploying a React app to Cloudflare Pages is straightforward. First, build your project by running npm run build. This creates a dist/ folder containing optimized, production-ready static files (HTML, CSS, and JavaScript bundles).

Then go to your Cloudflare dashboard, navigate to Workers & Pages, click Create, choose Pages, and upload the contents of your dist/ folder. Within seconds, your React app is live on a global CDN with HTTPS.

One important detail for SPAs: since React Router handles routing in the browser, you need Cloudflare to serve index.html for all paths. Create a _redirects file in your public/ folder with the content /* /index.html 200. This tells Cloudflare to route all requests through your React app, letting React Router handle the path resolution.

Building something real is the best way to learn. Reading tutorials only takes you so far. The act of debugging a broken fetch call or figuring out why your state isn't updating teaches more than any article.