React Foundations

Senior move: design the UI before writing any JSX. Sketch a wireframe/mock, then derive the component tree from it. Good planning makes the code almost write itself.

• Two levels of planning: first the visual layout, then break it into a component hierarchy. Naming the components up front is half the work.

Each piece is a functional component; the app is just components nested inside components (composition).

const AppLayout = () => (
  <div className="app">
    <Header />
    <Body />
    <Footer />
  </div>
);
root.render(<AppLayout />);

• Reusability is the reason to extract a component. The moment you'd repeat markup (e.g. many restaurant cards), make it its own component — same logic as extracting a function.

// inline = JS object, hence the double braces
<div style={{ backgroundColor: "#f0f0f0" }}> … </div>

• Double braces explained: outer { } = "JS goes here", inner { } = the object literal. Properties are camelCase (backgroundColor, not background-color).

Props (properties) are just the arguments you pass to a component function. React collects everything you pass into a single props object.

// pass props (like function arguments)
<RestaurantCard resName="KFC" cuisine="Burgers" />

// receive them — two equivalent styles
const RestaurantCard = (props) => ...props.resName...
const RestaurantCard = ({ resName, cuisine }) => ...  // destructure on the fly

• Destructuring on the fly ({ resName }) is plain JavaScript object destructuring — not React magic.
• Pass whole objects, not 10 separate props. <Card resData={obj} /> keeps the call clean; read it as props.resData. Note the { } — you're passing a JS object, not a string.

Big idea: you build the components once, and the data decides what shows up. Swiggy sends different offers and cards for Delhi vs. Mumbai — same app, different data, different page. If a section has no data, it simply doesn't appear. The data that controls this is the "config."

• UI layer + data layer. A strong front-end engineer owns both — you should be able to question an API's shape, not treat data as "the backend's problem."
• Real data is messy & deeply nested (e.g. resData.data.name). Use optional chaining (?.) to read it safely, and watch for redundant/duplicated fields in real APIs.

Don't hand-write N cards. Loop the data array with .map() inside JSX and return a component per item.

<div className="res-container">
  {resList.map((restaurant) => (
    <RestaurantCard key={restaurant.data.id} resData={restaurant} />
  ))}
</div>

• Prefer map/filter/reduce over for loops — functional style is the React norm and reads cleaner inside JSX.
• Build display strings in JSX, not in the API. e.g. {cuisines.join(", ")} or {"₹" + costForTwo/100 + " for two"}.

Every item you render in a .map() needs a unique key. It's not decoration — the key is how React identifies each item, so when the list changes it can update just the one that changed instead of redrawing all of them.

• Priority: unique id > index > no key. No key is unacceptable; index is a fallback only when no id exists (ask the backend for one).

Honest truth: anything React does, you could do with plain HTML/CSS/JS — React is JavaScript under the hood. The point of a library is developer experience: write less code, build more, and let React handle the hard part — keeping the screen in sync with your data, fast.

A 2,000-line App.js is unreadable. Split each component into its own file. The common convention: a src/ folder for source code, a components/ folder inside it, and a utils/ folder for shared things.

• Never hard-code data inside a component file. Move constants (CDN URL, logo) and mock data into utils/ so they're reusable and the component stays clean.
• Keep files small — a rough industry habit is to break a component up once it grows past ~100–200 lines. React itself has no opinion on folder structure; pick something simple and refactor as you grow.
• .js vs .jsx doesn't matter. Either works; just be consistent. Don't overthink it.

To use a component across files, you export it from its file, then import it where you need it (give before you take). Two flavors:

// DEFAULT — one per file
export default Header;
import Header from "./components/Header";

// NAMED — as many as you want, names must match
export const CDN_URL = "...";
import { CDN_URL } from "../utils/constants";  // note the { }

• Default = the file's main thing (usually a component); import it with any name, no braces. Named = pick specific things by exact name, wrapped in { }. A file can have one default but many named exports.
• The file extension is optional on import. "./components/Header" resolves to the .js file automatically.

Make the UI interactive by passing a function to events like onClick. The function runs when the event fires.

<button onClick={() => {
  console.log("clicked");
}}>Top Rated</button>

• Pass the function, don't call it. onClick={handleClick} — React calls it on click. Every DOM event has a React equivalent (onClick, onMouseOver, onChange…), all camelCased.

Say a button filters a list. You can write the filter in plain JS and the data changes — but the screen doesn't budge. A normal let variable has no way to tell React "I changed, redraw me." That gap is exactly what React's state solves.

A hook is just a JavaScript function React gives you with a built-in superpower. useState creates a state variable: a value React watches, plus a setter function to change it.

import { useState } from "react";   // named import

// [ current value, function to update it ]
const [listOfRes, setListOfRes] = useState(resList);  // arg = initial value

• The two parts: listOfRes is the current value; setListOfRes is the only correct way to change it. The argument to useState is the starting value.
• Never reassign state directly. listOfRes = [...] does nothing useful — you must call setListOfRes(newValue), which is what tells React to re-render.
• State is local to its component — scoped to that function, like any local variable.

This is the heart of React: whenever a state variable changes, React re-renders that component and updates the screen to match. Call the setter, and the UI follows automatically — you never touch the DOM yourself.

When people say "React is fast," they mean it's efficient at updating the DOM — the slow part of any web page. Here's how.

• Why this is fast: comparing two plain JS objects is cheap; rewriting real HTML is expensive. React diffs the cheap copies and touches the real DOM as little as possible.
• React Fiber is the name of React's current reconciliation engine (rewritten in React 16). It enables splitting rendering work into chunks. Interview-ready phrasing: "React does efficient DOM manipulation via a Virtual DOM and a diffing algorithm."

Two ways to structure a whole application's backend — useful context for where a React app fits.

• Separation of concerns / single responsibility — each service does one thing. Your React app is just the UI microservice; it calls a backend service to get data.
• Services connect by URL/port — e.g. UI on :1234, backend mapped to /api. Mix stacks freely (React UI, Java backend, etc.).

When should the API call happen relative to rendering? React favors the second option.

• Two renders is fine. React's render cycle is fast and cheap, so rendering twice for a smoother experience is a good trade.

useEffect takes two arguments: a callback function and a dependency array. The callback runs after the component finishes rendering — the perfect place for an API call.

import { useEffect } from "react";

useEffect(() => {
  fetchData();      // runs AFTER render
}, []);             // dependency array

• Order: the component renders first, then the effect's callback fires. (Log inside both and "body rendered" prints before "useEffect called.")
• The empty [] means "run once" — after the first render only. (More on dependencies in a later session.)

Fetching in React is plain JavaScript — fetch() is a browser superpower, not a React one. Resolve its promise with async/await (cleaner than .then() chains).

const fetchData = async () => {
  const data = await fetch(SWIGGY_URL);
  const json = await data.json();
  setListOfRes(json?.data?.cards…);  // drop into state → re-render
};

• Update state with the result. Calling the setter re-renders the component with live data — the same state-driven flow shown earlier.
• Real APIs are deeply nested & messy — you dig through paths like json.data.cards[2].data.data.cards. Use optional chaining (?.) to read it safely.

Calling another site's API from localhost often fails with a CORS error. It's the browser blocking requests from one origin to a different origin — a security policy, not a React bug.

• Why the proxy works: the browser only blocks browser cross-origin calls. A server has no such limit, so the proxy calls the API for you and hands back the data.
• Real production fix: the API's own server enables CORS for your origin, or your own backend proxies the request. Public proxies are rate-limited (~tens of calls/min) — fine for dev, not for scale.

While the API loads, don't show a blank page or a plain spinner — show a shimmer UI: fake skeleton cards that resemble the real layout. It's the modern standard (Swiggy, YouTube) and feels faster.

// conditional rendering with a ternary
return listOfRes.length === 0
  ? <Shimmer />
  : <div className="res-container">…</div>;

• Conditional rendering = rendering different JSX based on a condition. The if/else or a ternary (? :) is just JavaScript — the fancy interview name is the only new part.
• Empty list = data not here yet — listOfRes.length === 0 is the signal to show the shimmer.

A search box bound to state via value={searchText} is a controlled component — React owns its value. If you only set value and never update the state, typing appears frozen, because the box always shows the (empty) state.

<input
  value={searchText}
  onChange={(e) => setSearchText(e.target.value)}
/>

• The fix is onChange: on every keystroke, read e.target.value and update state. State → re-render → the box shows the new value. That two-way wiring is what makes a controlled input work.
• Every keystroke re-renders the component — and that's fine. React's diffing means only the input's value actually changes in the real DOM, so it stays fast even after dozens of renders.

On search, filter the data and update state — React re-renders with the matches. But filtering and overwriting your one list destroys the full data, so the next search has nothing to search.

• Keep two state variables: the full listOfRes (never mutated after fetch) and a filteredRes you render. Filter from the full list into the filtered one — so every search starts from all results.
• Make search case-insensitive — lowercase both sides and use .includes() (not ===) so "coffee" matches "Third Wave Coffee."

Live APIs change over time. The durable skill isn't memorizing one data path — it's reading the API off the real site instead of guessing when it breaks or you don't know its URL.

• Install a JSON viewer extension to read big responses; open the API URL in a tab and use it to explore/search the structure.

The response is one huge config-driven blob — offers, "what's on your mind," filters, and (somewhere) the restaurant list. Walk the tree to the part you actually need.

// the restaurants live deep inside; the exact path shifts over time
const restaurants =
  json?.data?.cards[5]?.card?.card
    ?.gridElements?.infoWithStyle?.restaurants;

• Config-driven UI, revisited: each top-level card builds one section (offers, filters, headings). You only pluck the card holding restaurants — which card index that is can change.
• Always use optional chaining (?.) so a missing intermediate doesn't crash the whole app.

When the shape changes, the fix is small — update the keys your card reads. In this change, the per-restaurant wrapper key data became info, and a couple of fields moved/changed type.

• Debug by reading the error + logging the object. "Cannot read properties of undefined (id)" points straight at the renamed path; log the restaurant to see the real keys.

The first call returns only ~9 restaurants. Scrolling triggers a separate POST API (passing lat/long) to load more — this is lazy loading / pagination.

• GET vs POST: a GET puts params in the URL; a POST sends a body. fetch(url, { method: "POST", body … }) for the "load more" call.