Thursday, October 8, 2026

REACT | SEE WHY COMPONENTS CHANGE THE WAY WE BUILD INTERFACES — How JavaScript, JSX, Components, Props, Rendering, and the UI Tree Work Together



A modern application can contain thousands of things a person can

see or interact with.

A button.

A search box.

A navigation bar.

A product card.

A shopping cart.

A notification.

A profile picture.

A payment form.

A dashboard.

A modal window.

At first glance, building such an interface appears to be a matter of writing HTML, adding CSS, and attaching JavaScript.

And that is exactly how the Web fundamentally works.

HTML describes structure. CSS describes presentation. JavaScript provides behavior.

So why did React become necessary?

The answer begins with a problem that appears when an interface stops being a document and becomes a living application.

Imagine an online store.

A customer searches for a product. The results change.

They add an item to the cart. The cart count changes.

They change the quantity. The price changes.

They log in. Their name appears.

They open a product. More information appears.

They apply a filter. Several parts of the screen change simultaneously.

Nothing about HTML itself prevents you from building this.

The difficulty is keeping a large, constantly changing interface consistent as the application grows.

React is built around a different way of thinking about that problem.

Instead of primarily thinking:

“What instructions should I give the browser to change this part of the page?”

you begin thinking:

“Given the application's current data, what should the interface look like?”

That shift is the foundation of React.

The Web already gave us the pieces

Before React, there was already a powerful model for creating interfaces.

You could write:

<h1>My Store</h1>
<button>Add to Cart</button>

CSS could determine how those elements look.

JavaScript could respond to events:

button.addEventListener("click", ...)

The browser turns the HTML into a DOM—the Document Object Model—which JavaScript can inspect and modify.

This is important because React did not replace the Web's underlying technologies.

A React application still runs in a browser.

It still ultimately produces browser-recognized elements.

It still uses JavaScript.

It still relies on HTML concepts.

It still uses CSS.

React sits on top of these technologies and introduces a way to organize interface logic.

The React documentation describes React as a library for building user interfaces from components. Components can be combined to create complete screens and applications.

So the first misconception to remove is:

React is not a replacement for HTML, CSS, and JavaScript.

React is a way of using JavaScript to organize and describe interfaces built from those underlying Web capabilities.

The problem becomes clearer when the interface has state

Consider a simple counter.

Initially:

Count: 0

The user presses a button.

Now:

Count: 1

Press it again:

Count: 2

The screen has changed because some information changed.

That information is the application's state.

You could manually find the element containing 0 and replace its text with 1.

That works.

But imagine a much larger interface.

The same state might affect:

  • a cart badge,
  • a checkout summary,
  • a product list,
  • a navigation menu,
  • a notification,
  • and a payment button.

Now the challenge becomes maintaining consistency.

If the underlying state says:

Cart contains 3 products

every relevant part of the interface should reflect that fact.

The fundamental problem is therefore not:

“How do I change this HTML element?”

It is:

“How should the interface be derived from the current state?”

That is the conceptual doorway into React.

React makes the interface a function of data

Imagine a component that receives:

name = "Ada"

and produces:

<h1>Hello, Ada</h1>

Conceptually:

data
  ↓
component
  ↓
interface

If the data becomes:

name = "Grace"

the desired interface becomes:

<h1>Hello, Grace</h1>

The component describes that relationship.

In React, a component is commonly a JavaScript function that returns JSX describing what should appear in the interface.

For example:

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

This looks almost like HTML embedded inside JavaScript.

But it is not ordinary HTML.

The syntax is called JSX.

And understanding why JSX exists requires understanding what a React component actually is.

A component is a piece of interface logic

Suppose you are building a video platform.

A video card might contain:

Thumbnail
Title
Description
Like button
Channel information

You could write all of this as one enormous page.

But the same structure might appear hundreds of times.

React gives you another possibility.

You define a reusable component:

function VideoCard({ video }) {
  return (
    <article>
      <img src={video.thumbnail} alt="" />
      <h2>{video.title}</h2>
      <p>{video.description}</p>
    </article>
  );
}

Then use it:

<VideoCard video={video1} />
<VideoCard video={video2} />
<VideoCard video={video3} />

The important idea is not that this saves typing.

The deeper idea is that you have created a named unit of interface behavior and structure.

You can now reason about the video card as one thing.

That is abstraction.

Components can contain other components

A useful interface rarely consists of isolated pieces.

A page might contain:

Application
 ├── Header
 │    ├── Logo
 │    ├── SearchBox
 │    └── AccountMenu
 │
 ├── Sidebar
 │    └── Navigation
 │
 └── MainContent
      ├── VideoList
      │    ├── VideoCard
      │    ├── VideoCard
      │    └── VideoCard
      │
      └── Footer

This is a hierarchy.

React is designed around composing components into larger interfaces. The official documentation uses this idea of components as reusable, nestable pieces of UI.

So instead of treating a page as one enormous thing, you can reason about it as a tree of components.

That tree becomes one of the most important mental models in React.

The UI becomes a tree

Imagine:

App
│
├── Header
│   ├── Logo
│   └── Search
│
├── ProductPage
│   ├── ProductImage
│   ├── ProductDetails
│   │   ├── Price
│   │   └── AddToCart
│   └── Reviews
│
└── Footer

Each component occupies a place in the tree.

A component can have children.

A parent can provide information to a child.

A child can respond to interaction.

The application can therefore be understood as a structured collection of relationships.

This is much easier to reason about than a giant collection of unrelated DOM manipulations.

React's documentation specifically encourages thinking about UI as a tree because this helps explain how components are structured and how information flows through an application.

JSX is where JavaScript meets interface structure

Consider:

function Product({ name, price }) {
  return (
    <article>
      <h2>{name}</h2>
      <p>₦{price}</p>
    </article>
  );
}

At first this can feel strange.

There is JavaScript:

function Product(...)

There is JSX:

<article>
  <h2>...</h2>
  <p>...</p>
</article>

And JavaScript expressions appear inside JSX:

{name}
{price}

The important idea is that JSX lets the component keep related interface structure close to the logic that produces it.

It is not literally HTML sitting inside a JavaScript file.

It is syntax that tools transform into JavaScript representations that React can work with.

This is why React documentation describes JSX as a syntax extension for JavaScript that lets developers write markup-like structures alongside rendering logic.

JSX is not a new language for the browser

The browser does not natively execute your React JSX component in the form you wrote it.

Development tooling processes your source code.

That tooling transforms JSX into JavaScript that can be executed by the application's runtime.

This gives us another layer:

Your React source
      ↓
JSX + JavaScript
      ↓
Development/build tools
      ↓
JavaScript application
      ↓
Browser
      ↓
React
      ↓
DOM
      ↓
Screen

The exact details depend on the React application setup.

But the larger lesson matters:

React development is part of a toolchain.

React itself is not the entire environment.

This is why a serious React education eventually has to teach the surrounding system:

  • JavaScript,
  • JSX,
  • package management,
  • development servers,
  • build tools,
  • browser behavior,
  • source control,
  • testing,
  • APIs,
  • deployment.

React is a component in a larger development ecosystem.

A component receives information through props

Consider:

function Product({ name, price }) {
  return (
    <article>
      <h2>{name}</h2>
      <p>₦{price}</p>
    </article>
  );
}

The component expects information.

Another component can provide it:

<Product name="Laptop" price={350000} />

The information passed into the component is called props.

You can think of props as the information a parent provides to a child.

Parent
  │
  │ props
  ▼
Child

This creates a predictable relationship.

For example:

<Product
  name="Laptop"
  price={350000}
/>

The Product component does not need to know where those values originally came from.

They might have come from:

  • a local array,
  • a database,
  • an API,
  • a search result,
  • a user's previous action,
  • another component.

The component only needs to know what it has been given.

This separation becomes extremely powerful as applications grow.

Data can flow through the component tree

Imagine:

App
 ↓
ProductPage
 ↓
Product

The application may have product data at the top.

It passes the relevant data downward.

App
 │
 │ product
 ▼
ProductPage
 │
 │ product
 ▼
Product

This produces a useful discipline:

A component should not need to know everything about the application.

It receives what it needs.

This makes components easier to reuse and reason about.

But as applications become larger, passing information through many layers can become inconvenient.

That problem eventually leads into more advanced state architecture and tools such as context and external state-management solutions.

For now, the important foundation is simple:

components can receive information from their parents.

Rendering is a calculation

Suppose:

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

You can think of rendering as a calculation:

props
  +
component logic
  =
desired UI

If:

name = Ada

the result is:

Hello, Ada

If:

name = Grace

the result is:

Hello, Grace

This is why React encourages declarative programming.

You describe what the interface should represent.

React handles the process of updating the rendered interface.

The official React documentation describes this as telling React what to render and letting React determine how to update the user experience.

Declarative does not mean passive

Suppose a user clicks:

Add to Cart

Something must happen.

The application needs to update its state.

React does not eliminate programming logic.

It changes where the emphasis lies.

Instead of manually saying:

Find this element.
Change its text.
Hide that element.
Show another element.
Update this badge.

you work toward:

The cart now contains three items.

Then the UI should reflect that state.

This is a major shift.

The programmer focuses increasingly on:

What is the application's state?

What should the interface look like for that state?

What events cause the state to change?

Interaction introduces state

Consider:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <>
      <p>Count: {count}</p>

      <button onClick={() => setCount(count + 1)}>
        Add
      </button>
    </>
  );
}

There are several concepts here.

count represents the current state.

setCount provides a way to request an update.

The button has an event handler.

When the user interacts with the button, the state changes.

React then renders the component again using the new state.

Conceptually:

User interaction
       ↓
State update
       ↓
New state
       ↓
React renders
       ↓
UI reflects new state

This is the beginning of understanding interactive React applications.

React's documentation describes state as information that changes over time and explains that updating state causes the component's displayed output to change.

The screen is not the source of truth

This distinction is extremely important.

A beginner may think:

“The number on the screen is 5.”

But the screen is only a representation.

The application has state:

count = 5

and the interface represents that state:

Count: 5

This means the interface can be regenerated from the underlying state.

Conceptually:

          STATE
            │
            ▼
        COMPONENT
            │
            ▼
        RENDERED UI

If the state changes:

          STATE
            │
            ▼
        COMPONENT
            │
            ▼
        NEW UI

That mental model becomes extremely useful when debugging.

If the screen is wrong, ask:

Is the state wrong?

If the state is correct, ask:

Is the component rendering it incorrectly?

If the component is correct, ask:

Is the browser or surrounding system doing something unexpected?

You are investigating the system instead of randomly changing code.

React components should be predictable

A component should generally calculate its output from its inputs.

For example:

function Price({ amount }) {
  return <strong>₦{amount}</strong>;
}

If amount is 5000, the component should consistently represent that value.

It should not secretly modify unrelated application state every time React renders it.

This is why React emphasizes purity.

React's current documentation states that components and Hooks should be pure, props and state should be treated as immutable snapshots for a render, and side effects should not happen during rendering.

This may sound like a small programming rule.

It is actually architectural.

If rendering can unexpectedly change the world, React becomes difficult to reason about.

If rendering primarily calculates the UI, React can safely perform rendering work as needed.

Rendering and side effects are different things

Suppose a component calculates:

const total = price * quantity;

That is rendering logic.

It calculates a value.

Now suppose the component needs to:

  • connect to a server,
  • interact with a non-React widget,
  • subscribe to an external data source,
  • synchronize with a browser API.

Those are interactions with something outside the component's pure rendering calculation.

React calls these Effects when they need to be synchronized with rendering.

The current React documentation emphasizes that Effects are for synchronizing with external systems and warns against using them merely to derive one piece of state from another.

That distinction will become important later in the React book.

For now, remember:

Rendering
    =
calculate what the UI should represent

Event
    =
respond to a specific user action

Effect
    =
synchronize with something external to React

Those three concepts should not be casually mixed together.

React does not mean “put everything in one component”

A common beginner mistake is to create:

App

and put the entire application inside it.

It might eventually contain:

  • navigation,
  • authentication,
  • product lists,
  • forms,
  • payments,
  • notifications,
  • dashboards,
  • settings.

The component becomes enormous.

The real power of components appears when responsibilities are divided deliberately.

For example:

App
├── Header
├── Navigation
├── ProductSearch
├── ProductList
│   └── ProductCard
├── Cart
│   └── CartItem
└── Footer

Now each piece has a conceptual boundary.

You can inspect ProductCard without mentally loading the entire application.

You can change Header without rewriting ProductList.

You can reuse ProductCard in another part of the application.

This is why component design is partly an exercise in system decomposition.

But not everything should become a component

There is another trap.

Once you discover components, you might create hundreds of tiny components for everything.

That can make an application harder to understand rather than easier.

The goal is not:

“Create as many components as possible.”

The goal is:

Create useful boundaries around meaningful pieces of interface and behavior.

A component should make the system easier to reason about.

If extracting something makes the code clearer, reusable, independently understandable, or easier to maintain, the boundary may be valuable.

If it merely adds another layer of indirection, it may not be.

Good React development is therefore not component multiplication.

It is component design.

The browser is still doing the final work

It is tempting to imagine React as drawing pixels directly onto the screen.

It does not.

A simplified path looks more like:

React components
       ↓
React rendering system
       ↓
Browser DOM
       ↓
Browser rendering pipeline
       ↓
Pixels

The browser remains responsible for the actual web platform.

This connects React directly to what you learned about browsers.

The browser understands:

  • HTML,
  • CSS,
  • JavaScript,
  • DOM,
  • events,
  • layout,
  • painting,
  • networking,
  • storage,
  • security boundaries.

React works within that environment.

This is why understanding the browser is such an important foundation for understanding React.

React gives you a different way to organize the application.

It does not abolish the Web underneath it.

Try seeing the component tree instead of the page

Take a small application:

function App() {
  return (
    <main>
      <h1>W3 NOTES</h1>
      <button>Subscribe</button>
    </main>
  );
}

Instead of seeing:

A page containing a heading and button

try seeing:

App
└── main
    ├── h1
    └── button

Now introduce a component:

function SubscribeButton() {
  return <button>Subscribe</button>;
}

function App() {
  return (
    <main>
      <h1>W3 NOTES</h1>
      <SubscribeButton />
    </main>
  );
}

The interface has not changed much visually.

But the structure has changed conceptually:

App
└── main
    ├── h1
    └── SubscribeButton

You have created a reusable boundary.

That is one of the simplest ways to begin thinking in React.

Now make the component reusable

Suppose you want:

Subscribe
Advertise
Contact

You could create three components.

Or you could make the button configurable:

function ActionButton({ children }) {
  return (
    <button>
      {children}
    </button>
  );
}

Then:

<ActionButton>Subscribe</ActionButton>
<ActionButton>Advertise</ActionButton>
<ActionButton>Contact</ActionButton>

Now the component provides a common structure while the parent provides the content.

This is the beginning of reusable component design.

But notice what happened.

We did not start by memorizing React APIs.

We started with a real interface problem:

Several pieces of the interface share a structure but differ in content.

React gives us a way to represent that relationship.

That is how the technology becomes understandable.

React is really about managing UI complexity

React is sometimes introduced as:

“A JavaScript library for building user interfaces.”

That description is accurate, but it does not explain why the technology matters.

The deeper problem is:

How do you keep a large, interactive user interface understandable as the number of states, interactions, and reusable pieces increases?

React addresses that problem with a model based around:

Components
     +
Props
     +
State
     +
Rendering
     +
Events
     +
Composition

Those concepts form the foundation.

Later, the system grows:

Components
    ↓
State
    ↓
Effects
    ↓
Data fetching
    ↓
Routing
    ↓
Forms
    ↓
Shared state
    ↓
Application architecture
    ↓
Testing
    ↓
Performance
    ↓
Deployment

But the later subjects only make sense if the foundation is solid.

React is also a programming environment, not just a UI trick

Once a React application becomes serious, you encounter another reality.

You need to manage:

  • source files,
  • dependencies,
  • packages,
  • development servers,
  • environment variables,
  • builds,
  • tests,
  • version control,
  • deployment,
  • APIs,
  • authentication,
  • backend systems.

React is therefore not the whole application.

It is one important layer within a larger software system.

The current React documentation recommends using a framework when starting a new application in many cases, while also explaining that React can be used from scratch when a framework is not appropriate or when learning the fundamentals. Create React App is deprecated.

That distinction matters.

Learning React itself and choosing an architecture for a production application are related but different decisions.

You should first understand what React is doing before allowing a framework to hide those mechanisms from you.

Your first React investigation

You can learn a surprising amount from one tiny component.

Start with:

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

Now investigate it.

What is Greeting?

A JavaScript function used as a React component.

Why does its name begin with a capital letter?

React distinguishes user-defined components from ordinary HTML tags by convention and syntax; component names begin with capital letters.

What is {name}?

A JavaScript expression embedded in JSX.

Where did name come from?

It came through the component's props.

What does the component return?

A description of the interface it wants React to render.

What happens if name changes?

The component can render a different result.

Is <h1> a custom React component?

No. It represents a built-in browser element.

Can Greeting contain other components?

Yes.

And that final question leads naturally to the next layer of the React model.

The interface becomes a language you can compose

Imagine defining:

function Logo() {
  return <strong>W3 NOTES</strong>;
}

function SearchBox() {
  return <input placeholder="Search" />;
}

function Header() {
  return (
    <header>
      <Logo />
      <SearchBox />
    </header>
  );
}

Now:

function App() {
  return (
    <>
      <Header />
      <main>
        <h1>Welcome</h1>
      </main>
    </>
  );
}

You have effectively created a small language for your application's interface:

App
 ├── Header
 │    ├── Logo
 │    └── SearchBox
 │
 └── Main

This is the deeper power of components.

You stop describing every detail of the entire interface in one place.

Instead, you build a vocabulary.

That vocabulary lets you express increasingly complicated interfaces in terms of concepts you have already defined.

This is the same idea that functions introduced in programming:

small operation
      ↓
named function
      ↓
larger program

React applies a similar principle to interface structure:

small UI piece
      ↓
component
      ↓
component composition
      ↓
screen
      ↓
application

Where this chapter leaves you

You should now be able to look at a React application differently.

It is not simply:

HTML + JavaScript

It is a structured system in which:

  • components represent reusable pieces of interface and logic;
  • JSX lets JavaScript describe interface structure;
  • props allow components to receive information;
  • state represents information that changes over time;
  • events provide a way to respond to user actions;
  • rendering calculates what the interface should represent;
  • composition combines smaller components into larger interfaces;
  • the component tree provides a model of the application's UI structure;
  • React manages the relationship between changing application state and rendered UI;
  • the browser remains the underlying Web platform.

The most important change is therefore not that you have learned a new syntax.

It is that you have acquired a different way of seeing an interface.

A page is no longer merely a collection of HTML elements.

It can be understood as a tree of components whose rendered output depends on data and state.

That mental model will carry much further than any particular React API.

The next problem is now obvious.

If components are functions and the interface is derived from data, how do components actually manage changing information, respond to users, share data, and preserve the right state as the application becomes larger?

That is where the next layer of React begins. 


Image: GeeksForGeeks 

at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)