Chapters

Hide chapters

React Apprentice

First Edition · web · React 8.0.0 · Visual Studio Code

Section I: Rendering Right

Section 1: 7 chapters
Show chapters Hide chapters

2. Why React Exists
Written by Eli Ganim

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous chapter, you set up your workspace, created the Learning Tracker project and rendered your first value with a pair of curly braces. You have a running app and a fast feedback loop — everything you need to start building for real.

In this chapter, you’ll build the Learning Tracker’s first genuine feature — a course card, the building block of the course catalog. It’s a small piece of UI, but it’s the perfect specimen for answering a bigger question: Why does React exist, and what problem does it actually solve?

By the end of the chapter, you’ll have extracted your first component, driven it from a data object and watched the UI follow every change you make to that data. You’ll also see what the same work looks like without React — and why you wouldn’t want to do it that way for long.

Building Your First Course Card

The Learning Tracker’s home screen will eventually show a catalog of courses. Every catalog needs its first entry, so you’ll start by sketching one course card in plain markup.

Replace the entire contents of src/App.tsx with:

import './App.css'

function App() {
  return (
    <main>
      <h1>Learning Tracker</h1>
      <p>Your course catalog starts here.</p>
      <article>
        <h2>React Basics</h2>
        <p>Build interfaces from reusable components.</p>
        <p>Level: Beginner</p>
      </article>
    </main>
  )
}

export default App

Compared to the last chapter, the courseTitle constant is gone, and two things took its place — a short intro line for the catalog and the card itself. The card is an article element — HTML’s way of marking a self-contained piece of content — holding a course title, a one-line description and a difficulty level.

Save the file and check the browser:

The first course card, straight from your markup.
The first course card, straight from your markup.

There’s your card. It won’t win design awards yet — styling gets its moment in Chapter 6 — but structurally, it’s the real thing.

Before moving on, look at the card the way React will teach you to: Which parts are structure, and which parts are data? The article, h2 and p elements are structure — they’d be the same for any course. But “React Basics”, the description and “Beginner” are data. They just happen to be trapped inside the markup. You’ll free them soon.

Extracting Your First Component

Right now, the course card lives inside App. Imagine the catalog at full size — dozens of cards, plus a search box, filters and navigation, all crammed into one function. You’d scroll forever to find anything.

function CourseCard() {
  return (
    <article>
      <h2>React Basics</h2>
      <p>Build interfaces from reusable components.</p>
      <p>Level: Beginner</p>
    </article>
  )
}
function App() {
  return (
    <main>
      <h1>Learning Tracker</h1>
      <p>Your course catalog starts here.</p>
      <CourseCard />
    </main>
  )
}

Components Are Functions That Return UI

Step back and look at what your file describes now, because this shape — a tree of components — is the shape of every React app you’ll ever build:

The Learning Tracker's component tree: App at the root, with elements and components as branches.
Nju Xuildotw Xzeczes'f lunmupinz dbia: Acw uj tqo yiac, japt ajonamhb uyp cutwahoxhd oq mtirknow.

Separating Data From Markup

You identified the card’s trapped data earlier: title, description, level. Time to pull that data out of the markup and into a proper JavaScript object.

const course = {
  title: 'React Basics',
  description: 'Build interfaces from reusable components.',
  level: 'Beginner',
  isFavorite: true,
}
<article>
  <h2>{course.title}</h2>
  <p>{course.description}</p>
  <p>Level: {course.level}</p>
</article>

Letting TypeScript Watch Your Back

First, a quick experiment. You never told TypeScript what shape course has, yet it knows. Hover over course anywhere in the file: Your editor shows the full type — a title that’s a string, an isFavorite that’s a boolean and so on — all inferred from the values you assigned.

Property 'titel' does not exist on type '{ title: string;
description: string; level: string; isFavorite: boolean; }'.
Did you mean 'title'?

Showing the Favorite Message

The isFavorite property is still invisible. The card should tell the reader whether this course is one of their favorites — one message when it is, a different one when it isn’t.

let favoriteMessage = 'Not in your favorites yet'
if (course.isFavorite) {
  favoriteMessage = 'One of your favorites'
}
<p>{favoriteMessage}</p>
The card now reflects the isFavorite boolean.
Zca sibk baf wekmapbz fli omXukorabo fuaxoid.

Changing the Data

You’ve been told twice that the UI follows the data. Time to see it with your own eyes.

Different data, different card — and you never touched the markup.
Mufxaposp xeta, joczelorh falc — abj kuu yivax fuuzpuv tbo rewtuv.

Why React Works This Way

You’ve now experienced React’s approach: describe the UI once, feed it data. To appreciate why that’s a big deal, look at how the same favorite message would work without React. You don’t need to type this — just read it:

const message = document.querySelector('#favorite-message')
if (course.isFavorite) {
  message.textContent = 'One of your favorites'
} else {
  message.textContent = 'Not in your favorites yet'
}
The render produces a fresh UI description; the commit updates the browser to match.
Hza sotsat snagacex i jlohf OO busdhoygueq; wpa kuvwul umnehoy nvi dmistol li yesrz.

Challenge: Build Your Dream Course Card

Your turn to fly solo. This challenge has two parts:

Key Points

  • A component is a function that returns a description of UI, and its name must start with a capital letter.
  • Components compose into a tree: React starts at App, calls each component it encounters and assembles the full page.
  • Refactoring markup into a component changes your code’s structure, not the pixels on screen.
  • Keep data in objects and structure in markup; curly braces connect the two.
  • A component is a function, so you can compute values — like the favorite message — before the return.
  • To change the UI, change the data, not the page.
  • Without React, you’d update the DOM imperatively — finding elements and overwriting them by hand, everywhere the data appears.
  • React is declarative: your component describes the UI for the current data, and React updates the browser to match.
  • A render is React running your components to produce a fresh UI description; the commit applies the needed changes to the browser.
  • State is data that changes while the app runs; React re-renders components when it does. You’ll create your first state in Chapter 8.
  • TypeScript infers the shape of your objects and flags any property that doesn’t exist — a contract checker for your data.

Where to Go From Here?

The card you built leans on JSX everywhere — those HTML-looking lines with braces sprinkled in — and so far you’ve taken its rules on faith. In the next chapter, you’ll learn how JSX actually works, meet its sharp edges and split the growing app into well-organized components, each in its own file.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now