Module 31: Introduction to React

Why each option is right or wrong

• “You declare every variable at the top of each file before using it” (Incorrect): That's a coding style, not what declarative means in React.
• “You write each step to find and change every element on the page yourself” (Incorrect): That's the imperative approach, which React saves you from.
• “The page is drawn once and doesn't change after it loads” (Incorrect): React pages update whenever the data changes.
• “You describe the screen for the current data, and React makes the page match” is correct.

  Instead of writing step-by-step instructions like "find this element, change its text", you write what the screen should look like for the data you have. When the data changes, React works out what to update on the page.

  • Imperative: you give each step to change the page yourself.
  • Declarative: you describe the result; React does the steps.

📖 Revise: Lesson 1: Why React exists

Why each option is right or wrong

• “Yes, React saves all component data to the cloud automatically” (Incorrect): React has no built-in cloud storage. Saving needs a backend.
• “Yes, as long as you build the app with npm run build” (Incorrect): Building produces files for hosting; it doesn't add storage.
• “Yes, it keeps everything in the browser until the user logs out” (Incorrect): React's data is lost on refresh unless you save it somewhere.
• “No; storing data needs a backend and database” is correct.

  React runs in the visitor's browser and only holds data while the page is open. Refresh, and that data is gone unless it was saved somewhere: a server with a database, or at least the browser's local storage.

  • React's job: showing the screen and responding to clicks.
  • Saving for everyone: a backend and a database.

📖 Revise: Lesson 1: Why React exists

Why each option is right or wrong

• “dev is for Windows computers and build is for Macs” (Incorrect): Both commands work on any operating system.
• “build installs the packages; dev runs the tests” (Incorrect): Installing is npm install; tests are usually npm test.
• “They do the same thing, but build shows fewer messages in the terminal” (Incorrect): They do different jobs: one serves while you work, the other prepares files for hosting.
• “dev runs a live development server; build creates optimised files for hosting” is correct.

  npm run dev starts a local server that updates the page as soon as you save a file, for working on the app. npm run build produces a dist folder of small, optimised files that you upload to a host.

  • dev: fast feedback while you work, not for real visitors.
  • build: what goes live.

📖 Revise: Lesson 2: Setting up with Vite

Why each option is right or wrong

• “className makes the CSS load faster in the browser” (Incorrect): It's only a naming difference; CSS speed is the same.
• “class only works on div elements in React” (Incorrect): class isn't used in JSX at all, on any element.
• “className lets one element have several styles, which class can't” (Incorrect): HTML class already allows several names; the change is only to avoid the reserved word.
• “class is a reserved word in JavaScript” is correct.

  JSX is turned into JavaScript, where class already means something: it defines a class. To avoid the clash, React uses className for the HTML class attribute.

  • Similar case: htmlFor instead of for on labels.
  • Result in the page: it still becomes class="..." in HTML.

📖 Revise: Lesson 3: JSX

Why each option is right or wrong

• “No, any HTML inside the message will run as code” (Incorrect): React escapes text in braces, so HTML in it is shown, not run.
• “Only if you wrap it in dangerouslySetInnerHTML first” (Incorrect): That does the opposite: it switches off the protection.
• “No, you need to remove every capital letter first” (Incorrect): Capital letters have nothing to do with safety.
• “Yes, JSX escapes it so it's shown as text” is correct.

  When you put a value in curly braces, React treats it as text, so any <script> or HTML tags in it appear as characters instead of running. This protects against a common attack called cross-site scripting.

  • The risky exception: dangerouslySetInnerHTML skips this protection.
  • Links: still check URLs a visitor supplies, such as in href.

📖 Revise: Lesson 3: JSX

Why each option is right or wrong

• “React picks whichever of the two was imported most recently in the file” (Incorrect): Import order doesn't decide it; the first letter does.
• “The self-closing slash makes it a component” (Incorrect): Both examples have the slash; the capital letter is the difference.
• “They're the same; React ignores capital letters in tag names” (Incorrect): Case matters: it's how JSX tells components from HTML tags.
• “Lower-case names are HTML tags; capitalised names are components” is correct.

  JSX uses the first letter to decide. Lower-case means a built-in HTML element; a capital letter means a component you've defined or imported. So components must start with a capital.

  • Common bug: naming a component header makes React look for an HTML tag instead.
  • Convention: components use PascalCase, like EnquiryList.

📖 Revise: Lesson 4: Components

Why each option is right or wrong

• “It has more than three lines of code inside it” (Incorrect): Short components are fine, but three lines is not a meaningful limit.
• “It uses several props passed in from its parent component above it” (Incorrect): Using props is normal and expected.
• “It's used in more than one place across the app” (Incorrect): Reuse is a good thing and isn't a reason to split.
• “It does several jobs, or is too long to understand at a glance” is correct.

  A component that fetches data, filters it, shows a table and runs a form is hard to read, test and reuse. Splitting it into smaller components, each with one job, makes every piece simpler.

  • Rough guide: if you need to scroll a lot to read it, consider splitting.
  • Name test: if a good name needs "and", it's doing two jobs.

📖 Revise: Lesson 4: Components

Why each option is right or wrong

• “Copied into each component that uses it, so each stays independent” (Incorrect): Copies drift apart over time and stop matching each other.
• “Inside main.tsx, since that's where the whole app starts and loads from” (Incorrect): main.tsx starts the app; types are easier to find in their own file.
• “In the CSS file, alongside the component's styles” (Incorrect): CSS can't hold TypeScript types.
• “In a shared types.ts, so every component uses the same definition” is correct.

  If several components each define their own version of Enquiry, they can drift apart and disagree. One definition in a shared file means a change is made once and TypeScript checks every component against it.

  • Import it: import type { Enquiry } from "./types".
  • Single source of truth: one place to update.

📖 Revise: Lesson 5: Project structure and your first screen

Why each option is right or wrong

• “The node_modules folder, to find the broken package” (Incorrect): node_modules has thousands of files; the error message points you to the real problem.
• “The browser's saved passwords and cookies” (Incorrect): These don't explain a blank React page.
• “Your computer's system settings for display problems” (Incorrect): A blank page here is a code error, not a display setting.
• “The terminal running npm run dev” is correct.

  The development server reports build problems, such as a syntax error or a missing import, in the terminal. The browser console shows errors while the page runs. Checking both often reveals the cause quickly.

  • Browser console: errors while the page runs.
  • Terminal: errors while the code is being built.

📖 Revise: Lesson 2: Setting up with Vite

Why each option is right or wrong

• “Pages are written in HTML; components are written in JavaScript” (Incorrect): Both are React components written in the same way.
• “React only loads files inside the pages/ folder” (Incorrect): React loads whatever you import; folder names are your choice.
• “Components run on the server; pages run in the browser” (Incorrect): In this setup both run in the browser.
• “Components are reusable pieces; pages are whole screens built from them” is correct.

  A button, a card or a badge goes in components/ and can be used anywhere. A page, like the dashboard or the settings screen, combines components into one full screen.

  • It's a convention: React doesn't require these folder names.
  • Benefit: you can find things quickly as the project grows.

📖 Revise: Lesson 5: Project structure and your first screen