Setting up a React project with Vite
The mental model: how React renders (2)
You've written components, passed props, rendered lists, and conditionally shown UI. Before we move on to state next week, it's worth pausing to understand what React is actually doing when it runs your code.
This mental model will make everything in the coming weeks click into place.
https://www.youtube.com/watch?v=724nBX6jGRQ
When you load a React app, this is the sequence:
<App />)Touching the real DOM is slow. React batches and minimizes those touches. This is why you describe the end state and let React figure out how to get there.
https://www.youtube.com/watch?v=ARWX1XdghLk
Your app is a tree of components. <App /> is the root. Every component it renders is a branch. Every component those render are further branches.
<App />
│
┌──────────────┼──────────────┐
│ │ │
<Header /> <UserList /> <Footer />
│
┌────────┼────────┐
│ │ │
<User/> <User/> <User/>
This tree mirrors the structure of your DOM. React walks it from top to bottom, calling each function, collecting the JSX each one returns.
Now ask yourself: where does the user data live, and where does it need to go? If <App /> has the list of users, it passes it down to <UserList />, which passes individual users to each <UserCard />. Data flows in one direction — downward through props.
A child component cannot reach up and change its parent's data. Data only flows down.
This constraint makes React apps predictable. If something on the screen looks wrong, you don't need to check the whole app — you trace upward through the tree to find where that data comes from.
Next week you'll learn that a child can trigger a change in a parent — but it does so by calling a function the parent passed down as a prop. The parent always controls its own data.
<aside> 💡
Info
This is the same one-way data flow introduced back in the Why React lesson. Now that you've built components and passed props, it should feel more concrete. When you add state next week, you'll see exactly why this constraint exists.
</aside>
https://www.youtube.com/watch?v=7sgBhmLjVws
This is the most important thing to internalize before next week.
Every time a component renders, the entire function body runs again from top to bottom.
function Counter({ count }: { count: number }) {
console.log('Counter rendered with count =', count);
const doubled = count * 2;
return <p>{count} doubled is {doubled}</p>;
}
If the parent re-renders Counter five times, you'll see five console logs and doubled recalculated five times. Every variable in the function body is recalculated on every render.
This is why you can't store changing data in a regular variable inside a component — it gets reset on every render. State has to live somewhere that survives between renders. That's what useState solves, and it's exactly what we'll cover in week 8.
<aside> ⌨️
Hands On
Add console.log('Rendered!') inside one of the components you built earlier. Open the browser console and reload the page — you'll see it log once on initial load. Now make a small change to a prop or piece of data and save the file. Watch the console.
This is React doing its job: your function runs, React gets a new description of the UI, it diffs against the previous one and updates only what changed.
</aside>
The virtual DOM is just a JavaScript object — a description of what your UI should look like. React keeps two copies: the previous render and the current one. It diffs them (reconciliation), computes the minimal set of changes, and applies those changes to the real DOM.
You never interact with this directly. It's internal to React. But it's why the mental model is "describe the result" rather than "tell the browser what to do."
<aside> ⌨️
Hands On
Take one of the component trees you built earlier — your landing page from the Components lesson works well. Draw it on paper or a whiteboard:
Then trace the render order out loud: which functions does React call, and in what order, when <App /> first renders?
</aside>
Everything you've learned this week fits into this model.
Components are functions React calls to get a description of the UI. JSX is what those functions return — a lightweight description, not real DOM elements. Props are the arguments React passes to those functions, flowing downward through the tree. Lists are arrays of JSX that React renders in order, using keys to track items across renders. Conditional rendering is just JavaScript that decides which description to return.
React takes all of those descriptions, builds a tree, diffs it against the previous tree, and updates the DOM as efficiently as it can.
<aside> 🎉
Celebration
You've covered the full foundation of React in one week — components, JSX, props, lists, conditional rendering, and now the mental model behind all of it. Everything from week 8 onwards builds directly on what you've learned here. State, effects, data fetching, routing — it all runs on this same engine.
</aside>
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.