React Essentials: From Imperative to Declarative UI

1. In vanilla JS you’d write h1.textContent = newTitle to update a heading. What is the declarative React equivalent?

• Call React.update(h1, newTitle) to tell React what changed
• Change the data (a variable or, later, state) — React re-runs the component function and patches the DOM automatically
• Use document.querySelector inside the component to directly update the DOM element
• Manually traverse the Virtual DOM and apply diffs

2. What does Babel compile <h1>Hello</h1> into?

• A raw HTML string injected via innerHTML
• React.createElement('h1', null, 'Hello') — a plain JS object describing the UI node
• A direct document.createElement('h1') call that creates a real DOM node immediately
• A WebAssembly instruction that the browser renders natively

3. A teammate proposes: “Instead of learning React, let’s just use vanilla JavaScript with document.getElementById — it’s more direct and we already know it.” Evaluate this suggestion for a project with 50+ interactive UI components that update frequently.

• They’re right — vanilla JS with direct DOM manipulation is always simpler, faster, and more maintainable than using a framework
• For a small page, vanilla JS is fine, but with 50+ components, manually tracking DOM updates becomes error-prone. React eliminates stale-UI bugs
• React is always the better choice regardless of project size — even a static landing page benefits from the Virtual DOM’s efficiency
• They should use jQuery instead — it offers the same declarative model as React but with a smaller bundle size

1. Why does React use className instead of class for CSS classes?

• React invented its own HTML attribute names to distinguish itself from plain HTML
• class is a reserved keyword in JavaScript, so JSX (which is valid JS) uses className to avoid a syntax conflict
• React’s virtual DOM uses a different internal representation where class has a different meaning
• className is faster for the browser to process than class

2. Why must JSX components return a single root element?

• React can only diff trees that have one root; multiple roots would break the reconciliation algorithm
• This is a browser limitation — the DOM only allows one child per script
• React.createElement returns a single object, so a function returning multiple top-level JSX elements would be returning multiple objects, which isn’t valid in JS without an array
• It’s a style convention, not a technical requirement — React ignores extra roots

3. How do you write an inline style with font-size: 18px and color: red in JSX?

• style="font-size: 18px; color: red"
• style={{ fontSize: "18px", color: "red" }}
• style={{ "font-size": 18px, color: red }}
• style={fontSize: "18px", color: "red"}

4. Analyze this code. A student writes function card() { return <div>A card</div>; } and uses <card />. It renders an empty box. Why?

• Components must extend React.Component — plain function components cannot return JSX without a base class
• React uses capitalization: lowercase → HTML element, uppercase → component. <card /> becomes an unknown HTML tag
• The function body is missing return — without it, the JSX is created but never returned to React for rendering
• JSX only supports standard HTML tag names — custom element names must be registered via React.registerElement()

5. Which of these are correct JSX? (Select all that apply) (select all that apply)

• <img src={url} alt='logo' />
• <div class='container'>...</div>
• <p>{user.name.toUpperCase()}</p>
• <button onclick={handleClick}>Click</button>

1. Inside a component, you have function Card({ title }) { title = 'New'; ... }. What is wrong with this?

• Nothing — props can be freely reassigned inside the component
• Props are read-only (like const function parameters) — mutating them breaks React’s one-way data flow and causes unpredictable behaviour
• You must use this.title to access props in function components
• The destructuring syntax { title } is invalid — you must write props.title

2. Which of these is the correct way to pass a number prop to a component?

• <Card price="99.99" />
• <Card price={99.99} />
• <Card price=99.99 />
• <Card price=(99.99) />

3. Analyze this: <Card title="React" /> and <Card title={"React"} /> produce the same result. When would they differ?

• They never differ — both syntaxes are always identical
• They differ for strings — quotes produce a string, braces produce a symbol
• They are the same for string literals, but only {} works for expressions: title={getTitle()} is valid, title=getTitle() is not
• {} is faster because it skips string parsing

4. A ProductCard receives price as a prop and renders ${price.toFixed(2)}. What happens if the parent passes price={undefined}?

• React renders $undefined as text — ugly but harmless
• The call undefined.toFixed(2) throws a TypeError and the component crashes
• React silently ignores the undefined prop and renders $0.00 as a default
• The component renders but .toFixed(2) returns the string 'NaN'

1. Why doesn’t let count = 0; count++; cause the UI to update in React?

• You must use var instead of let to make React track the variable
• React’s reconciler only re-renders when state changes — mutating a local variable does nothing to signal React; useState’s setter is the trigger
• Arrow functions prevent React from seeing variable assignments
• React automatically batches all updates, so count++ is delayed by 500ms

2. What is wrong with this code? if (isLoggedIn) { const [user, setUser] = React.useState(null); }

• useState cannot store null as an initial value — only strings, numbers, and booleans are supported
• Hooks must be called at the top level of a component — calling useState conditionally breaks React’s internal order-tracking and causes crashes
• You cannot use const with array destructuring in React — let is required for state variables
• There is nothing wrong — React handles conditional hook calls automatically using internal tracking

3. You have const [items, setItems] = React.useState([]). How do you correctly add an item?

• items.push(newItem) — then React detects the array was mutated
• setItems(items.push(newItem)) — push returns the new length, passing it to setItems
• setItems([...items, newItem]) — create a new array with the spread operator and pass it to the setter
• items[items.length] = newItem; setItems(items) — modify in place then re-set

4. A teammate proposes storing the counter value in a global variable outside the component instead of using useState, arguing “it’s simpler and doesn’t reset.” Evaluate this approach — what breaks?

• Nothing breaks — global variables persist across renders and React detects changes to them automatically
• The global variable persists, but changing it doesn’t trigger a re-render — the UI stays frozen. Also, if the component is used twice, both instances share the same global, causing conflicts
• Global variables bypass the Virtual DOM diffing process, making them significantly slower than useState
• React throws a strict-mode error when it detects global variable access inside any component function

5. (Spaced review — Step 2: JSX) A student’s component renders but looks wrong: the heading has no CSS class applied, clicking does nothing, and the image tag causes a syntax error. Which combination of JSX rules is being violated?

• Using class instead of className, onclick instead of onClick, and <img> without self-closing />
• Using className instead of class, onClick instead of onclick, and missing the src attribute
• Forgetting to wrap JSX in a Fragment, using an inline style string, and missing a key prop
• Using lowercase component name, returning multiple root elements, and missing curly braces around a variable

1. Why is it dangerous to use the array index as a key for a dynamic list?

• Array indices are numbers, but React requires string keys — converting indices to strings adds overhead
• If items are reordered, inserted, or removed, the index of items changes — React maps keys to component instances, so incorrect keys cause wrong state to be associated with the wrong component
• Using indices is significantly slower because React must convert each numeric index to a string internally
• Array indices are not globally unique across sibling lists, causing key collisions and rendering conflicts

2. You need to render a list of user cards. Which key strategy is correct?

• users.map((user, index) => <Card key={index} user={user} />)
• users.map(user => <Card key={user.id} user={user} />)
• users.map(user => <Card key={Math.random()} user={user} />)
• users.map(user => <Card key={user} user={user} />)

3. (Spaced review — Step 3: Props) A TaskItem component needs to let the user mark a task as done. The task data comes from the parent via props. Which approach is correct?

• task.done = true inside TaskItem — mutate the prop directly since it is the same object
• Add const [done, setDone] = useState(task.done) inside TaskItem — duplicate the prop into local state
• Call a callback prop from the parent: onToggle(task.id) — let the parent update the data and pass new props down
• Use document.getElementById to update the checkbox directly in the DOM

1. What does {showBadge && <Badge />} render when showBadge is false?

• The text false
• An empty <div> placeholder to preserve layout space
• Nothing — false is not rendered by React
• A Badge component with visible={false} passed automatically

2. Analyze this bug: {count && <Badge count={count} />}. When count is 0, a 0 appears in the UI instead of nothing. Why?

• React treats all numbers as truthy in boolean contexts, including zero, so 0 && always renders the right side
• Unlike false, null, and undefined, the number 0 IS a valid React node — React renders it as text. Use {count > 0 && <Badge />} instead
• The && operator does not work with numbers in JavaScript — it is designed only for boolean operands
• This is a known React bug in the reconciler that incorrectly renders falsy values, expected to be fixed in React 19

3. Evaluate two approaches to implementing filters: A: Store the full filtered array in state: const [visibleTasks, setVisibleTasks] = useState(allTasks) B: Store only the filter string in state: const [filter, setFilter] = useState('all') and derive visible tasks with .filter() Which is better?

• A is better — pre-filtering into a separate state variable avoids recomputing the filter on every render
• B is better — derived data should be computed from minimal state, not stored separately. A duplicates data, creating sync bugs when the source changes
• Both are equivalent in behavior and performance — choose whichever approach matches your team’s coding style
• Neither is correct — filtered data should be managed through React Context to avoid prop drilling

4. (Spaced review — Step 4: useState) A shopping cart component has this handler:

function handleBuyTwo() {
  setCart([...cart, product]);
  setCart([...cart, product]);
}

• 3 — each call adds one item to the existing cart
• 2 — React batches both calls; both see the same stale cart (length 1) and both set it to length 2
• 1 — React ignores the second setter call because the value is identical
• Error — you cannot call the same setter twice in one handler

5. (Spaced review — Step 1: Declarative vs Imperative) A counter component needs to display the count and update when clicked. A student proposes three approaches. Which is correct? A: document.getElementById('count').textContent = newCount B: const [count, setCount] = useState(0); return <p>{count}</p>; C: let count = 0; return <p>{count}</p>; with count++ on click

• A — direct DOM update is the most straightforward way to change displayed text
• B — declarative state with useState: React re-renders when the setter is called, keeping UI and data in sync
• C — a plain variable is simpler than useState and works the same way
• All three work — they are different syntaxes for the same result

1. React favors composition over inheritance. Which statement best explains why?

• JavaScript does not support class inheritance, so React has no choice
• Deep class hierarchies in UI code are hard to reason about — composition using the children prop and smaller components gives more flexibility and avoids the ‘fragile base class’ problem
• Inheritance is strictly slower than composition at runtime in JavaScript
• Composition is only preferred for functional components; class components still use inheritance

2. What does the children prop give you?

• A list of all child elements in the DOM tree below the component
• The ability to nest arbitrary JSX between a component’s opening and closing tags, letting it act as a generic container
• A reference to the child component’s internal state
• An array of all React components currently mounted in the application

3. A <SearchBar> and <ProductTable> are siblings. The user types in SearchBar and the table should filter. Where should filterText state live?

• filterText lives in SearchBar — ProductTable reads it via a React ref
• filterText lives in the common ancestor — passed as a prop to both; SearchBar calls an onFilterChange callback prop
• filterText is stored in localStorage so both components can access it
• filterText lives in ProductTable — SearchBar directly mutates it

4. A <UserCard> needs a user prop from a grandparent, passing through <Profile> which doesn’t use it. What is this antipattern called?

• The God Object pattern
• Prop drilling — threading props through intermediate components that don’t need them
• Composition — combining components to build a larger UI
• Lifting state up

5. (Spaced review — Step 5: Lists & Keys) A drag-and-drop todo list lets users reorder items. Each item has a text input for editing. The current code uses key={index}. A user drags item C from position 3 to position 1. What happens to the text typed into item A’s input field?

• Item A’s text stays with item A — React tracks components by their content
• Item A’s text moves to item C — because React maps state to keys, and item A’s key (0) now points to item C after reordering
• All text inputs are cleared — React destroys and recreates the entire list on reorder
• Nothing changes — React ignores key props for stateful inputs and uses the DOM position

1. Evaluate this code for a mini store. What are the bugs?

function App() {
  let cart = [];
  const addToCart = (product) => { cart.push(product); };
  return (
    <div>
      {products.map(p => <ProductCard product={p} onAdd={addToCart} />)}
      <p>Cart: {cart.length} items</p>
    </div>
  );
}

• The code is correct — it will work as expected
• Two bugs: (1) cart is a local variable, not state — pushing to it won’t trigger re-renders. (2) .map() is missing key props
• The only bug is that push is slow — should use concat instead
• addToCart should be defined outside the component for performance

2. Analyze the component design of a store app. A student puts product rendering, cart management, filtering, and the total calculation ALL in the App component. What is wrong with this approach?

• Nothing wrong — keeping everything in one component is simpler and avoids the overhead of passing props between components
• It violates single-responsibility: each concern (product display, cart, filters) should be its own component. A monolithic component is hard to test, hard to reuse, and hard to modify without breaking other features
• React enforces a 100-line limit per component — exceeding this causes a build-time warning in strict mode
• It is slower because React’s Virtual DOM diffing algorithm has O(n²) complexity for components over 500 lines

3. In the mini store, both ProductCard (to show “In Cart” status) and CartSummary (to show the total) need access to the cart array. Where should cart state live?

• In ProductCard — each card tracks whether it’s in the cart
• In CartSummary — the cart summary owns the cart data
• In the nearest common ancestor of both (likely App) — passed down as props with an addToCart callback
• In a global variable outside all components

4. (Spaced review — Step 6: Conditional Rendering) A product card should show “In Cart” only when the product is already in the cart array. Which JSX pattern is correct?

• {cart.includes(product) ? <span>In Cart</span>} — ternary with one branch, since we only need the truthy case
• {cart.filter(item => item.id === product.id).length > 0 && <span>In Cart</span>} — && short-circuit with ID-based lookup
• {if (cart.includes(product)) return <span>In Cart</span>} — use an if-statement inside the JSX expression braces
• <span visible={cart.includes(product)}>In Cart</span> — use the built-in visible prop to toggle display