⚛️ React: Reading the Source

React: Reading the Source: A React component is like a MOLD in a LEGO-BRICK FACTORY: you write the `BugCard` mold once, then a card is stamped from that mold for each bug.

A React component is like a MOLD in a LEGO-BRICK FACTORY: you write the `BugCard` mold once, then a card is stamped from that mold for each bug. The "material" poured into the mold is the prop (the bug's data), and the mold's output is the real DOM produced by JSX. Why should a tester be able to read React source? Because if they can SEE that a line writing `className={styles.card}` produces a hashed class like `class="BugCard_card__x7f2a"` in the browser, they understand in advance that locating by it will break. Java analogy: component is like a metot/class, a prop like a parameter, state like an instance field, and a re-render like calling the method again with new arguments. In QA context: a tester who reads JSX and pictures the DOM it will produce speaks the same language as the developer and picks the right locator from the start. Throughout this group you will see a Source -> DOM -> Locator board for each of the BugCard, Modal, StatusBadge, and Toast components.

📜 F1. What Is a Component? Function -> JSX -> DOM

A React component is not a mysterious "UI piece", it is a PLAIN JavaScript function — like a METHOD in Java taking a parameter and returning a result. `function BugCard({ bug })` is a method, `bug` is its parameter, and `return ... ` is the VALUE the method returns — but this value is not real DOM, it is a JSX "RECIPE". So why is knowing this distinction useful? Because React TAKES this recipe and turns it INTO real DOM ITSELF (reconciliation) — there is a conversion step BETWEEN what the component returns and the real node in the browser. Java analogy: like the difference between a method saying `return new Button()` and that Button object actually being DRAWN on screen — RETURNING an object and DRAWING it on screen are separate steps. In QA context: a tester who sees a component as a function thinks about "how does the DOM change if this component is called again (re-render)?" the SAME way they would think about "what does this method return if called with different arguments?" in Java.

🎬 A Component Is a Function: a Prop Flows In, JSX Flows Out

function BugCard(props)

A React component may look mysterious at first, but it is really a PLAIN JavaScript function. In this film you will watch HOW the `BugCard` component gets called by React, HOW the prop flows in, and HOW the returned JSX turns into real DOM.

Step 1 — the React engine CALLS `BugCard`: just like calling a method in Java, `BugCard(props)` runs. The prop (`{ bug: {...} }`) flows into the function like a PARAMETER.

Step 2 — the prop flows in and the function BODY runs: fields like `bug.status`, `bug.title` are read, a condition (`{isOpen && ...}`) is evaluated if needed — up to this point there is NO DOM change yet, only JS is running.

Step 3 — the function RETURNS JSX: this JSX is NOT real DOM — it is only a RECIPE saying "I want a structure like this" (in fact, behind the scenes, it is a plain JS object made of `React.createElement(...)` calls).

Final — React turns this RECIPE into real DOM: React compares the returned JSX against the previous state (reconciliation) and creates/updates the REAL DOM nodes. THIS is where a locator actually targets — not the JSX, but the RESULT of this step.

A developer says "my component said `return ... `, so a ` ` was added to the DOM". What is the technical gap in this statement?

No gap, returning means it was added to the DOM

What is returned is not real DOM but a JSX recipe; React TAKES it and turns it into real DOM via reconciliation — a separate step

This is only true for class components