Foundations · Part II

The same hook from before, but the second argument (the dependency array) is what decides when the effect runs. There are exactly three cases, and interviewers love this one.

// 1 - runs after every render
useEffect(() => { ... });

// 2 - runs once, after the first render
useEffect(() => { ... }, []);

// 3 - runs whenever btnName changes
useEffect(() => { ... }, [btnName]);

• The callback is required; the array is optional. Adding the array is what changes the timing — it's a filter on "when should this re-run."
• Why fetch with []: you want the API call once, not on every keystroke or click. An empty array says "set this up after the component first appears, then leave it alone."

State variables belong inside a component function, declared at the very top — before any logic. Putting a hook inside an if, a loop, or a nested function breaks React.

• Inside the component only: declaring state outside the function throws "Invalid hook call — hooks can only be called inside the body of a function component." State is local to a component, so it has to live there.
• At the top: declare all your useState / useEffect calls first, before branching or returning. This keeps their order identical on every render.
• Never in if /for /nested functions: a hook inside a condition might run on some renders and skip on others. React tracks hooks by call order, so a changing order corrupts which state belongs to which variable.

React itself doesn't do URLs — it renders components. To map URLs to components you add a routing library; the standard choice is React Router DOM, installed like any package.

                        // install it like any npm package
                        npm install react-router-dom
                    

• It's just another dependency: installing adds it to package.json and package-lock.json, same as anything else.
• Version matters: the v6 API (used here) is different from v5 — older tutorials and projects may show the v5 style, so check the version before copying code.

You describe your routes as a plain list of objects — each says "for this path, render this element." Then you hand that config to a provider instead of rendering a single component directly.

import { createBrowserRouter, RouterProvider }
  from "react-router-dom";

const appRouter = createBrowserRouter([
  { path: "/",       element: <AppLayout />},
  { path: "/about",  element: <About />},
  { path: "/contact", element: <Contact />},
]);

// instead of rendering <AppLayout/>directly:
root.render(<RouterProvider router={appRouter} />);

• The config is data, not code branches: a list of { path, element } objects — React Router reads it and decides what to show for the current URL.
• Other router types exist (createHashRouter, memory, static) for special cases, but createBrowserRouter is the recommended default for web apps.

Hit an unknown URL and React Router shows its own error screen. You can replace it with your own by adding an errorElement, and read what went wrong with the useRouteError hook.

{ path: "/", element: <AppLayout />,
  errorElement: <Error />}

// inside the Error component:
const err = useRouteError();
return <h3>{err.status}: {err.statusText}</h3>;

• errorElement renders whenever a route throws or the URL doesn't match — so users see a friendly page, not React's raw red crash screen.
• useRouteError() hands you an error object (status, statusText, etc.) so you can show "404 — Not Found" instead of a generic message.
• Spot a hook by its name: anything starting with use is a hook — a function with a special purpose, by convention.

You usually want the header and footer to stay put while only the middle swaps per page. You do that by nesting routes as children of a layout, and marking where the child should appear with <Outlet />.

const appRouter = createBrowserRouter([
  { path: "/", element: <AppLayout />,
    children: [
      { path: "/",        element: <Body />},
      { path: "/about",   element: <About />},
      { path: "/contact", element: <Contact />},
    ],
  },
]);

// AppLayout renders the shell + an outlet
const AppLayout = () => (
  <div><Header /><Outlet />{/* child route renders here */}
</div>);

• The parent stays mounted: the layout (and its header) renders once; only the <Outlet /> contents change per route. That's how the header survives navigation.
• You won't find <Outlet> in the DOM: it's a placeholder — the matched child component takes its place in the rendered HTML.

An anchor tag works, but it reloads the entire app on every click — slow, and it throws away your loaded state. Inside React, navigate with <Link> instead.

• to instead of href: the only syntax difference. <Link to="/about">About </Link>.
• Under the hood, <Link> still renders an <a> — the browser only understands anchors. React Router wraps it, intercepts the click, and updates the view without a reload.

Because <Link> only swaps components, the app is a single page application — loaded once, then components interchange. That's client-side routing, and it's different from the old way.

• Don't confuse server-side routing with server-side rendering: routing is "where do pages come from on navigation"; rendering (SSR) is "where the HTML is first generated." Different topics.

You don't write a route per restaurant. You write one route with a variable segment — marked with a colon — and one component that loads whatever id is in the URL.

{ path: "/restaurants/:resId",
  element: <RestaurantMenu />}

// /restaurants/425  -> resId = "425"
// /restaurants/229  -> resId = "229"

• :resId is a placeholder: the colon tells React Router this part of the path is dynamic. Any value slots in and the same <RestaurantMenu /> renders.
• One reusable component, dynamic data: the markup is identical for every restaurant — only the data loaded inside it changes. That's reusability.

To fetch the right data, the component needs the id from the URL. The useParams hook gives you an object of the dynamic segments; destructure the one you named.

import { useParams } from "react-router-dom";

const { resId } = useParams();

useEffect(() => { fetchMenu(); }, []);

const fetchMenu = async() => {
  const data = await fetch(MENU_API + resId);
  const json = await data.json();
  setResInfo(json.data);
};

• The key matches the route: you named it :resId in the path, so useParams() returns { resId }. Destructure it on the fly.
• Build the API URL from the param: MENU_API + resId — same component, different restaurant, just by changing the id in the URL.
• Keep API URLs in a constants file rather than hard-coded in the component — cleaner and reusable.

Fetch into state, show a shimmer until it arrives, then render the list. Two traps appear here — reading into null, and rendering a list without keys.

const[resInfo, setResInfo] = useState(null);

// early return - guards against null before render
if (resInfo === null) return <Shimmer />;

const { name, cuisines } = resInfo?.cards[0]?.card?.card?.info;
const itemCards =
  resInfo?.cards[2]?.groupedCard?.cardGroupMap
    ?.REGULAR?.cards[1]?.card?.card?.itemCards;

return (
  <ul>{itemCards.map((item) =><li key={item.card.info.id}>{item.card.info.name}
      </li>)}
  </ul>);

• Early return beats a ternary here: if resInfo is null, return the shimmer before any code tries to read .name off null. A ternary in the JSX still runs the destructuring above it — and crashes.
• Always pass key in a .map(): without it React warns "each child in a list should have a unique key." Use a stable id, never the array index.
• Optional chaining everywhere in deep data: live JSON is deeply nested and shifts over time —?. stops one missing field from crashing the whole render.
• Live APIs change: the exact card indices and field names drift. Don't panic — open the network tab, find the current API and shape, and adjust the path. The knowledge transfers even when the data doesn't.

You won't reach for them in new code — functional components with hooks are the modern standard. Three reasons to know them anyway.

A functional component is a function that returns JSX. A class component is a class that extends React.Component and has a render() method returning JSX. That's the core difference.

import React from "react";

// functional: a function returning JSX
const User = () => return <div>...</div>;

// class: extends React.Component, render() returns JSX
class UserClass extends React.Component {
  render() {
    return <div>...</div>;
  }
}

• extends React.Component is what tells React "this is a class component" so it tracks and manages it. React.Component is a base class you inherit from, imported from react.
• Import styles vary: you'll see extends React.Component or, with a named import, extends Component. Same thing — don't let the two forms confuse you.
• Import/export is identical to functional components — nothing special needed to use a class component once it's defined.

Passing props is the same. Receiving them differs: a class takes them in its constructor, calls super(props), and then reads them anywhere via this.props.

// passing - same as functional
<UserClass name="Akshay" location="Dehradun" />class UserClass extends React.Component {
  constructor(props) {
    super(props);
  }
  render() {
    const { name, location } = this.props;
    return <h2>{name} —{location}</h2>;
  }
}

• All props arrive as one object: everything you pass is bundled into a single props object handed to the constructor.
• Read with this.props: use this.props.name anywhere in the class, or destructure for cleaner code — the same on-the-fly destructuring you use in functional components.
• Why super(props): you're extending a base class, so you must call its constructor first — and passing props up is what makes this.props available inside the constructor. (Classic interview "why" question.)

Where functional components use useState, a class keeps all its state in one object, this.state, set up in the constructor. You update it only through this.setState — never by assignment.

constructor(props) {
  super(props);
  this.state = {
    count: 0,
    count2: 2,   // one object holds every state variable
    };
}

// update - NEVER this.state.count = ... directly
this.setState({ count: this.state.count + 1 });

• One object, many variables: unlike multiple useState calls, a class groups all state into the single this.state object. (Behind the scenes, React keeps functional state as one object too.)
• Never mutate directly: this.state.count = 5 won't re-render and creates inconsistencies — the class equivalent of the "don't reassign state" rule. Always go through setState.
• setState merges, not replaces: pass only the keys you're changing and React leaves the rest untouched. It diffs, updates those variables, and re-renders. You can batch several keys in one call.

When a class component loads (we say it mounts — an instance of the class is created), three methods run in a fixed order.

• Mounting = creating an instance: "loading a class component" means a new instance of the class is created, which is why the constructor runs first (constructors run on instantiation, not invocation).
• componentDidMount runs last, only after React has actually put the component on the DOM — hence the name. That timing is the whole point of the next section.

React splits mounting into two phases. This is the key to the trickiest interview question: the order of lifecycle calls when a parent has multiple children.

// parent with two class children, the real order:
parent constructor
parent render
  first child constructor
  first child render      // render phase batched
  second child constructor
  second child render
  first child componentDidMount   // commit phase batched
  second child componentDidMount
parent componentDidMount
                    

• The surprise: the first child's componentDidMount does not fire right after its render. React runs the render phase for all children first, then the commit phase for all of them.
• Why batch: updating the real DOM is the slowest part. By computing all the diffs first (cheap, in-memory virtual DOM) and committing once, React minimizes expensive DOM work — that's a big reason it's fast.

In a class, you fetch data in componentDidMount — the same role useEffect(fn, []) plays in functional components. The reason is the two-phase timing.

async componentDidMount() {
  const data = await fetch(GITHUB_API);
  const json = await data.json();
  this.setState({ userInfo: json });
}

• Render fast, then fill: the component mounts immediately with default/empty state (so the user sees something), then the API call runs and setState re-renders with real data. React doesn't wait on the network to paint.
• Why after mount: because componentDidMount fires once the DOM is already on screen — the ideal moment to kick off a fetch without blocking the first paint.

After mounting, any setState starts an update cycle: React re-runs render (not the constructor — that runs once), updates the DOM, then calls componentDidUpdate.

componentDidUpdate(prevProps, prevState) {
  // the old pain: manual guards to avoid infinite loops
    if (this.state.count !== prevState.count) {
    // run effect for count change
    }
}

• Constructor runs once; render runs every update. Mounting fills state with defaults; each setState re-renders with the new values and then fires componentDidUpdate.
• This is where hooks shine: the messy prevProps /prevState comparisons (one per variable, easy to get wrong) collapse into one dependency array —useEffect(fn, [count]). That's the pain the array was designed to remove.

Just before a component leaves the screen, componentWillUnmount runs. In a single-page app the page never reloads, so anything you started — timers, subscriptions — keeps running unless you stop it here.

componentDidMount() {
  this.timer = setInterval(() => {
    console.log("still running…");
  }, 1000);
}

componentWillUnmount() {
  clearInterval(this.timer);  // stop the leak
}

• The SPA leak: a setInterval started in componentDidMount keeps firing after you navigate away — and starts a new one each time you return. Several stale timers pile up invisibly and degrade performance.
• The fix: store the timer id on this (shared across all the class's methods) in componentDidMount, and clearInterval it in componentWillUnmount. Create a mess, clean the mess.
• Hooks equivalent: return a cleanup function from useEffect — it runs on unmount, doing the same job as componentWillUnmount.

// functional cleanup - the modern equivalent
useEffect(() => {
  const timer = setInterval(..., 1000);
  return () => clearInterval(timer); // runs on unmount
}, []);

Each component (it's just a function) should do one thing well. If a component is doing several jobs, break it into smaller pieces — that's modularity.

• One job per component: a RestaurantCard takes props and renders a card — nothing more. A reader should grasp it at a glance.
• Why it pays off: small, focused pieces are reusable (drop the card anywhere), maintainable (find code fast), and testable (write a test per unit, so a bug is caught in the small piece, not hunted across a giant component).
• No hard rule: there's no exact line for "too much" — the aim is keeping components light and readable for the next person.

A hook is a normal JavaScript helper function with React powers (it can hold state, run effects). You've used library hooks (useState, useEffect, useParams ) — you can write your own the same way.

• Don't panic at the word "hook": it's a utility function. Your custom hook is no different from useParams — someone just wrote logic inside it and returned a value.
• The point: move a chunk of logic out of a component and into a hook, so the component gets lighter and the logic becomes reusable.

The menu component had two jobs: fetch the data and display it. Pull the fetching into a hook so the component is left with one job — displaying.

// utils/useRestaurantMenu.js
import { useState, useEffect } from "react";
import { MENU_API } from "../utils/constants";

const useRestaurantMenu = (resId) => {
  const[resInfo, setResInfo] = useState(null);

  useEffect(() => { fetchData(); }, []);

  const fetchData = async() => {
    const data = await fetch(MENU_API + resId);
    const json = await data.json();
    setResInfo(json.data);
  };

  return resInfo;        // the contract: in resId, out resInfo
};
export default useRestaurantMenu;

// the component is now clean - one job: display
const resInfo = useRestaurantMenu(resId);
                    

• Think in contracts: before writing a hook, fix its input and output. Here: in a restaurant id, out the restaurant info. The rest is implementation the caller never sees.
• It can hold its own state: a hook uses useState /useEffect just like a component — React tracks it the same way.
• Convention: one hook per file in a utils folder, named after the hook.

A second hook to cement the pattern: report whether the user is online. Its contract takes no input and returns a boolean — useful for online/offline dots, "you're offline" screens, or an offline mini-game.

const useOnlineStatus = () => {
  const[online, setOnline] = useState(true);

  useEffect(() => {
    window.addEventListener("offline", () => setOnline(false));
    window.addEventListener("online",  () => setOnline(true));
  }, []);

  return online;
};

// use it anywhere, in one line
const online = useOnlineStatus();
return online ? <Cards />: <h1>You're offline </h1>;
                    

• Browser event listeners: window fires online and offline events. Register them once inside a useEffect with [], flip the state, return it.
• Reusability in action: the same one-line hook powers the offline screen in the body and a green/red status dot in the header — write once, use anywhere.
• Tip: test offline behavior with the browser's Network tab "Offline" / throttling toggle, not by killing your Wi-Fi.

Start every hook's name with use (lowercase). It isn't strictly required, but it's strongly recommended — and most projects' linters enforce it.

• Signals "this is a hook": the use prefix tells React (and your teammates) the function follows hook rules and may hold state/effects — not a plain helper like getOnlineStatus.
• Linters enforce it: a React-configured ESLint will error if you skip use. Follow the convention the library recommends rather than fighting it.

A bundler (Parcel here) takes all your files and bundles them into one JavaScript file the browser loads. Fine for a small app — but as components grow into the thousands, that single file balloons and slows the first load.

• One file ships everything: home, about, contact, every route's code — all in one bundle, even though the user may never visit most of it.
• Neither extreme works: one giant file is too heavy to download; thousands of separate files means too many browser requests. The answer is something in between.

Break the app into smaller bundles loaded on demand. You'll hear this called many things — they all mean the same thing.

• Split along features: bundle by logical area — e.g. a food-delivery chunk and a separate grocery chunk — so each is a small app inside the big app.
• Why it's a senior-level topic: in front-end system-design interviews, knowing when and how to split bundles is exactly what signals you can build large, performant apps.

Replace a normal import with React's lazy, which takes a function that dynamically import s the component. React then loads that code only when the route is visited — and you wrap it in Suspense to show a fallback while it loads.

import React, { lazy, Suspense } from "react";

// not a normal import - loaded on demand
const Grocery = lazy(() => import("./components/Grocery"));

// wrap it so React has something to show while it loads
{ path: "/grocery",
  element: (
    <Suspense fallback={<h1>Loading…</h1>}><Grocery /></Suspense>) }

• What it does: the main bundle no longer contains the grocery code. Visiting /grocery triggers a separate grocery.js request — the code arrives only on demand.
• Why Suspense is required: while the chunk is downloading, the component isn't there yet. React "suspends" rendering and throws an error unless you provide a Suspense boundary with a fallback to show meanwhile (a "Loading…" message or a shimmer).
• The win: a few lines keep the initial bundle small, so a large app loads fast. Lower bundle size is the whole goal — this is how you fight app "bloat."

Before picking one, know the landscape. Each approach styles the same UI — the differences are in ergonomics, scale, and team preference.

Tailwind's pitch: style your components without leaving your JSX. Rather than naming a class and writing its CSS elsewhere, you apply many small classes — each does one CSS thing — directly in the markup.

• One class = one rule: flex →display:flex, w-56 →width:14rem, p-4 →padding:1rem. You compose the look from small pieces.
• Same mental model as CSS: you still think "make this flex, add padding, set width" — you're just expressing it as class names instead of a stylesheet.

Tailwind isn't React-specific — it works with any framework or plain HTML. Setup with Parcel is a few steps; follow the framework guide that matches your bundler.

                        /* index.css - the only CSS you write */
                        @tailwind base;
@tailwind components;
@tailwind utilities;
                    

// tailwind.config.js - where Tailwind looks for classes
content: ["./src/**/*.{html,js,jsx,ts,tsx}"], 

• PostCSS does the work: Tailwind runs on PostCSS (a tool that transforms CSS via JavaScript). The .postcssrc file tells your bundler to read Tailwind — you don't have to learn PostCSS separately.
• The content array lists where your classes live so Tailwind knows which files to scan. List only the file types you actually use.
• Those three @tailwind lines are the entire stylesheet — after adding them, you may never touch the CSS file again.

Tailwind's class names follow consistent shorthand. Learn the pattern once and most classes become predictable.

You build a layout by stacking utilities. And when the scale doesn't have the exact value you need, escape to a custom one with square brackets.

// a header laid out with utilities
<div className="flex justify-between items-center shadow-lg" ><img className="w-56" /><ul className="flex" ><li className="px-4" >Home </li></ul></div>
// arbitrary value when no class fits exactly
<div className="w-[200px]" >...</div>
                    

• Compose, don't author: a card is just m-4 p-4 w-[250px] rounded-lg shadow-lg — assembled from utilities, no separate CSS rule.
• Arbitrary values: w-[200px] sets an exact size the scale doesn't offer. Use the built-in scale by default; reach for brackets only when you truly need a specific value.
• You're not handicapped: hover states, complex layouts, even intricate components are all doable — there's a class for essentially everything.

The Tailwind CSS IntelliSense VS Code extension is what makes utility-first practical — you don't memorize classes, you get suggestions as you type.

• Autocomplete: start typing pink or shadow and it lists matching classes — no trips to the Tailwind website.
• Hover to inspect: hover any class to see the exact CSS it generates (e.g. w-56 →width: 14rem ).
• If suggestions stall: trigger them manually with Ctrl +Space .

Tailwind is a tradeoff. The wins are speed and a tiny CSS bundle; the costs are a learning curve and busier markup.

A useful mental model: the UI layer is the static JSX you render, and the data layer (state, props, local variables) is what drives it. The UI is powered by the data — get the data layer right and the UI follows.

• UI is "dumb": JSX just displays what it's given. All the logic — what to show, when it changes — lives in the data layer.
• Why it matters: managing data well is what separates a junior build from a senior one. Most of this guide is about handling that data layer cleanly.

A higher order component is a function that takes a component and returns a new, enhanced component. It doesn't change the original — it wraps it to add features (a label, extra props, behavior).

// contract: in a component, out an enhanced component
const withPromotedLabel = (RestaurantCard) => {
  return (props) => (
    <div><label className="absolute" >Promoted </label><RestaurantCard {...props} />
// pass props through
    </div>);
};

// build the enhanced version, use it conditionally
const RestaurantCardPromoted = withPromotedLabel(RestaurantCard);
{resData.info.promoted
  ? <RestaurantCardPromoted resData={resData} />: <RestaurantCard resData={resData} />}

• It's just a function: takes a component in, returns a component out. The returned thing is itself a functional component returning JSX.
• Keep it pure: an HOC doesn't modify the input component's code — it wraps and enhances it. Spread the props ({...props} ) down so the wrapped component still receives everything it needs.
• Use it for: reusable enhancements — adding a label, injecting props, layering behavior — without duplicating the base component.

A component is uncontrolled when it manages its own state, and controlled when its parent drives it through props. There's no strict definition — it's about where the source of truth lives.

• Why make it controlled: when sibling components need to coordinate — like an accordion where opening one closes the others — a single owner (the parent) must decide who's open.
• It's a spectrum: a controlled component can still have minor local state; what matters is that the main state driving it comes from the parent.

To let a parent coordinate its children, move the state out of the children and up into the parent. The parent holds one piece of state and passes both the value and a setter down.

// parent (RestaurantMenu) owns which one is open
const[showIndex, setShowIndex] = useState(null);

{categories.map((cat, index) => (
  <RestaurantCategory
    data={cat}
    showItems={index === showIndex}        // controlled
    setShowIndex={() => setShowIndex(index)} // callback down
    />))}

• The child no longer owns the state: it reads showItems from props and calls the setShowIndex callback on click — so the parent's single showIndex decides which accordion is open.
• How a child updates the parent: you can't reach into a parent's state directly. Instead the parent passes a function down; the child calls it, and the parent updates its own state. Data flows down, events flow up.
• Result: only one accordion open at a time — coordination that's impossible when each child manages itself.

The React DevTools browser extension adds two tabs to your console —Components and Profiler — that make the data layer visible.

• Components tab: shows the component tree (a view of the virtual DOM) on the left and the selected component's props and state on the right — you can watch each accordion's showItems flip live.
• Profiler tab: records interactions and shows which components re-rendered and how long each took — how you find slow components in a large app.
• Note: extra nodes like RouterProvider in the tree come from libraries (React Router), not your code — don't panic when you see them.

React data flows one way: parent → child → grandchild. To get data to a deeply nested component, you pass it through every component in between — even ones that don't use it. That's prop drilling.

• The problem: intermediate components become unwilling couriers, threading props they don't use. One or two levels is fine; ten levels deep is a mess.
• Don't abandon props: state and props are the heart of React — this isn't a reason to stop using them. It's a reason to avoid drilling the same data through many layers.

Context is React's built-in fix for prop drilling: a shared space any component can read from, no matter how deeply nested — ideal for data needed in many places, like the logged-in user or the theme.

// utils/UserContext.js
import { createContext } from "react";
const UserContext = createContext({ loggedInUser: "Default User" });
export default UserContext;

// read it in a functional component with a hook
const { loggedInUser } = useContext(UserContext);

// read it in a class component with Consumer
<UserContext.Consumer>{(data) => <h1>{data.loggedInUser}</h1>}
</UserContext.Consumer>

• createContext makes the context with a default value. Two ways to consume it: the useContext hook (functional components) or Context.Consumer with a callback (class components, which can't use hooks).
• What belongs in context: only data genuinely shared across many components — logged-in user, theme, etc. Don't dump everything into context; props are still right for local, parent-to-child data.
• It crosses lazy boundaries: a lazily-loaded page (e.g. About) still reads the current context value when it finally loads — the shared space persists.

To replace the default value, wrap part of your tree in Context.Provider and pass a value. Bind that value to state, and the whole subtree updates live when the state changes.

const[userName, setUserName] = useState();

// tie context to state - everything inside re-reads on change
<UserContext.Provider value={{ loggedInUser: userName, setUserName }}><AppLayout /></UserContext.Provider>

• Provider sets the value: everything wrapped inside reads that value instead of the default. Wrap the whole app for global data, or just one branch (e.g. only the header) to scope it.
• Bind to state for live updates: put the state value and its setter into value. Now any component can read the user and call setUserName — type in an input anywhere and every consumer updates instantly.
• Providers nest: an inner provider overrides an outer one for its subtree. Header inside its own provider can show "Elon Musk" while the rest of the app shows "Akshay Saini" — the closest provider wins.

Both give you a central store readable from anywhere. The difference is what they are and when you reach for them.

• Don't reach for Redux too early: a small or medium app rarely needs it — context handles shared data well. Redux earns its keep when the app gets big and you want its extra tooling and conventions.

Redux is a standalone state-management library, popularly paired with React but not built into it — and not required. You built this whole app for 11 sessions without it.

• Not mandatory: small and mid-size apps don't need it — props and context handle them fine. Reach for Redux when the app is large, data is heavily shared, and many components read/write the same state.
• It's separate from React: a common interview confusion is thinking Redux is React. It isn't — you install it. Alternatives like Zustand exist too.
• Why it helps at scale: a predictable central store plus excellent debugging tools (Redux DevTools) make big apps easier to reason about.

Old "vanilla" Redux was complex, needed many extra packages, and demanded lots of boilerplate. Redux Toolkit (RTK) is the standard way to write Redux today — less code, less setup.

• Two libraries do the job: install both —@reduxjs/toolkit for Redux logic and react-redux to wire it into React.
• Why RTK exists: it directly addresses old Redux's three pain points — too complicated, too many packages, too much boilerplate.

The store is one big object kept in a central place that any component can read or write. To stay organized, you split it into slices (logical partitions: a cart slice, a user slice, a theme slice…).

• The one line to memorize: clicking Add dispatches an action, which calls a reducer function, which updates a slice of the store — and because the component is subscribed via a selector, it updates automatically.
• You can't touch the slice directly: Redux forbids modifying a slice outside this path. Every change goes dispatch → reducer.
• One big object is fine: keeping lots of data in the store is normal — slices just keep it tidy.

Create the store with configureStore (from RTK), then make it available to React by wrapping the app in <Provider> (from react-redux).

// utils/appStore.js
import { configureStore } from "@reduxjs/toolkit";
import cartReducer from "./cartSlice";

const appStore = configureStore({
  reducer: {                // the app's ONE big reducer
        cart: cartReducer,      // each slice plugs in here
    },
});

// App.js - provide the store to the whole app
<Provider store={appStore}><AppLayout /></Provider>

• Import from the right place: configureStore comes from RTK (a Redux job); Provider comes from react-redux (a React-bridge job). Knowing which is which is the whole point of two libraries.
• Provider scope: wrap the whole app for global access, or just a branch if only part needs the store — same idea as a context provider.

A slice bundles a name, its initial state, and its reducers. createSlice returns an object with auto-generated actions and a reducer — you export both.

import { createSlice } from "@reduxjs/toolkit";

const cartSlice = createSlice({
  name: "cart",
  initialState: { items: [] },
  reducers: {
    addItem: (state, action) => {
      state.items.push(action.payload);  // mutate directly
        },
    removeItem: (state) => { state.items.pop(); },
    clearCart: (state) => { state.items.length = 0; },
  },
});

export const { addItem, removeItem, clearCart } = cartSlice.actions;
export default cartSlice.reducer;

• Reducers map to actions: each function under reducers (e.g. addItem ) auto-generates a matching action you dispatch. A reducer receives (state, action) and changes state based on action.payload.
• Export both: the named actions (to dispatch) and the default reducer (to plug into the store). This syntax is what RTK expects — it's not arbitrary.
• reducer vs reducers: the store takes one big reducer (singular, a combination of slice reducers); a slice defines many reducers (plural). A classic mix-up — watch the s.

To change the store, get the dispatch function from useDispatch and dispatch an action with your data. Whatever you pass becomes action.payload in the reducer.

import { useDispatch } from "react-redux";
import { addItem } from "../utils/cartSlice";

const dispatch = useDispatch();

const handleAddItem = (item) => {
  dispatch(addItem(item));   // item becomes action.payload
};

• Payload plumbing: Redux wraps your argument into an action object { type, payload } and hands it to the reducer as the second arg — so action.payload is whatever you dispatched.
• Pass a callback, don't call it: use onClick={() => handleAddItem(item)}, not onClick={handleAddItem(item)} — the second calls it immediately on render. (Plain JS, but a common bug.)

To read from the store, use the useSelector hook and select the exact slice portion you need. Doing so subscribes the component — it re-renders automatically when that data changes.

import { useSelector } from "react-redux";

// GOOD - subscribe to the smallest slice you need
const cartItems = useSelector((store) => store.cart.items);

// BAD - subscribing to the whole store
const store = useSelector((store) => store);
const cartItems = store.cart.items;

• Select the smallest portion: it's called a selector because you select a slice of the store. Subscribe to store.cart.items, not the whole store.
• Why it's a performance trap: subscribing to the whole store re-renders this component on any change anywhere — even unrelated slices (a user login affecting a cart component). Narrow selectors avoid that.
• Auto-update: once subscribed, dispatching elsewhere updates the slice and this component re-renders on its own — no manual wiring.

The biggest shift from old Redux: in RTK reducers you mutate state directly (state.items.push(...) ). Old Redux forbade this and forced you to return a new copy.

// OLD vanilla Redux - never mutate, return a new state
addItem: (state, action) => {
  const newState = { ...state };
  newState.items.push(action.payload);
  return newState;
}

// RTK - just mutate; no return needed
addItem: (state, action) => { state.items.push(action.payload); }

• Immer does the work: RTK uses the Immer library behind the scenes — it watches your "mutations," diffs old vs new, and produces a correct immutable copy. You write simple code; immutability still happens.
• Two valid options: either mutate the existing state, or return a brand-new state. RTK accepts both — but don't half-do it.
• Why state = [] fails: reassigning the state parameter just repoints a local variable — it doesn't mutate the real state Immer is tracking. Use state.items.length = 0 (mutate) or return a new object instead.

A browser extension that activates on any Redux app — a major reason to use Redux at scale, since it makes a busy store debuggable.

• Action log & diffs: every dispatched action appears with the new state and a git-style diff of exactly what changed.
• Time travel: jump to any past state, replay the user's actions, or skip an action — you can reproduce the exact moment a bug appeared.
• Trace & tests: it shows where each action was dispatched and even sketches a test case for the reducer.

Any line of code can introduce a bug — including a bug in a feature you weren't even touching. Automated tests catch those regressions before users do, which is why testing is part of writing the code, not a chore bolted on after.

• Where developers live: you mostly write unit and integration tests. E2E is a separate discipline with its own tooling.
• The payoff is regression safety: a passing suite means a change in one corner didn't silently break another. That confidence is the whole point.

React testing leans on a small stack. Each piece has one job; templates like Create React App wire it up for you, but doing it by hand once shows what each part is actually for.

// scaffolding the setup (Parcel project, by hand)
npm i -D @testing-library/react jest babel-jest @babel/core
npx jest --init        // no TS, env: jsdom, coverage: yes, clearMocks: yes
npm i -D jest-environment-jsdom   // Jest 28+ needs this separately
// package.json
"scripts" : {
  "test" : "jest",
  "watch-test" : "jest --watch" // re-runs on save, like HMR
}

• Two JSX errors you'll hit: "JSX isn't enabled" → add @babel/preset-react with { runtime: "automatic" }. "toBeInTheDocument is not a function " → import @testing-library/jest-dom, which adds the DOM matchers.
• Parcel vs Babel clash: Parcel runs its own transpilation; add a .parcelrc (or scope the Babel config) so the two don't fight over your files.
• Coverage folder: Jest writes a /coverage directory — add it to .gitignore so it doesn't pollute your history.

Before any React, the shape of a test is clearest on a plain function. A test is test("description", callback); inside, you expect(value).toBe(expected). That's the entire skeleton.

// sum.js
export const sum = (a, b) => a + b;

// sum.test.js
import { sum } from "./sum";

test("adds two numbers", () => {
  const result = sum(3, 4);
  expect(result).toBe(7);   // assertion
});

• expect is the assertion: it wraps a value, then a matcher (.toBe, .toEqual, .toBeTruthy …) states what should be true. .toBe uses Object.is under the hood.
• File conventions: Jest auto-finds files in a __tests__ folder (the double underscore is "dunder") or any file ending .test.js / .spec.js (and the .ts variants).

To test a UI component you first render it into jsdom, then reach into what was rendered through the screen object, then assert. screen exposes the queries; the most useful is getByRole.

import { render, screen } from "@testing-library/react";
import "@testing-library/jest-dom";   // gives toBeInTheDocument
import Contact from "../Contact";

test("should load Contact component", () => {
  render(<Contact />);                          // 1. render to jsdom
    const heading = screen.getByRole("heading");   // 2. query
    expect(heading).toBeInTheDocument();          // 3. assert
});

• Roles aren't tag names: an <input> 's role is textbox, not input. A wrong role won't crash silently — Jest lists the roles it actually found, which is how you discover the right one.
• Narrow an ambiguous query: pass an options object —getByRole("button", { name: "Login" }) — when several elements share a role.
• What a query returns: not a raw DOM node but a React element / fiber node — JSX is ultimately an object. Logging one shows an HTMLInputElement -like object with its props.
• Failures are generous: when an assertion fails, Jest prints the entire rendered HTML, so you can see exactly what was there versus what you queried for.

Use getBy* when you expect exactly one match — more than one is an error. Use getAllBy* when you expect several; it returns an array you can count.

// expecting many - returns an array
const inputs = screen.getAllByRole("textbox");
expect(inputs.length).toBe(2);
expect(inputs.length).not.toBe(3);   // .not inverts any matcher
// text queries accept a regex - looser matching
screen.getByText(/cart/i);   // matches "Cart - 0 items"
                    

• Singular query, plural match = crash: getByRole("textbox") with two text boxes throws. Switch to getAllByRole — the error message tells you to.
• Matchers are rich: toBe, toBeTruthy/Falsy, toBeGreaterThan, toBeNull, toBeNaN, and the .not inverter. Type a . after expect(x) and the editor lists them.
• Regex over exact strings: getByText("Cart - 0 items") is brittle; getByText(/cart/i) survives small copy changes.

jsdom understands JSX, but it doesn't know about Redux or React Router. Render a component that uses useSelector or <Link> on its own and it crashes — you must wrap it in the same providers the real app gives it.

import { render, screen, fireEvent } from "@testing-library/react";
import { Provider } from "react-redux";
import { BrowserRouter } from "react-router-dom";
import appStore from "../utils/appStore";
import Header from "../Header";

test("Header has a login button", () => {
  render(
    <BrowserRouter><Provider store={appStore}><Header /></Provider></BrowserRouter>);
  const btn = screen.getByRole("button", { name: "Login" });
  expect(btn).toBeInTheDocument();
});

• Read the failure to find the missing provider: "could not find react-redux context" → wrap in <Provider>. "error in Link component" → wrap in <BrowserRouter>. Each missing context fails with its own clear message.
• Same store as the app: import the real appStore so selectors resolve against actual initial state.

To simulate a user, import fireEvent from RTL. fireEvent.click triggers a click; fireEvent.change simulates typing — and you hand it the event object the browser would normally build.

// click toggles Login -> Logout
fireEvent.click(loginButton);
expect(screen.getByRole("button", { name: "Logout" }))
  .toBeInTheDocument();

// typing = a change event with a faked e.target.value
fireEvent.change(searchInput, {
  target: { value: "burger" },
});

• You fake the event object: in a real browser e.target.value comes from the DOM; in jsdom you supply { target: { value: "burger" } } yourself to mimic what an onChange handler receives.
• Assert the consequence, not the click: after firing, query for the new state (the "Logout" button, the filtered list) — that's what proves the behavior works.

A component that takes props (like a restaurant card) needs data supplied in the test. You don't hit the network — you create mock data: a JSON snapshot of a real response, kept in a /mocks folder and imported.

import MOCK_DATA from "../mocks/resCardMock.json";

test("renders card from props", () => {
  render(<RestaurantCard resData={MOCK_DATA} />);
  const name = screen.getByText("Leon's Burgers &Wings");
  expect(name).toBeInTheDocument();
});

• Where mock data comes from: log the real prop while the app runs, copy the object, and paste it into a JSON file. Now the test is deterministic and offline.
• Pass it as the prop: the mock fills the same prop the parent normally passes (resData ), so the component renders exactly as it would live.

An integration test renders a whole feature — e.g. the Body with its search box, cards, and API call. Because jsdom has no fetch (it's a browser superpower, not core JS), you replace global.fetch with a mock that resolves your mock data in the same promise shape.

import MOCK_RESLIST from "../mocks/resListMock.json";
import { act } from "react-dom/test-utils";

// fetch returns a promise -> json() returns a promise -> data
global.fetch = jest.fn(() => {
  return Promise.resolve({
    json: () => Promise.resolve(MOCK_RESLIST),
  });
});

test("search filters the list to 4 cards", async() => {
  await act(async() =>
    render(<BrowserRouter><Body /></BrowserRouter>)
  );

  const input = screen.getByTestId("searchInput");
  fireEvent.change(input, { target: { value: "burger" } });
  fireEvent.click(screen.getByRole("button", { name: "Search" }));

  const cards = screen.getAllByTestId("resCard");
  expect(cards.length).toBe(4);
});

• Match fetch's exact shape: real fetch resolves to a response whose .json() also returns a promise. Your mock must nest Promise.resolve({ json: () =>Promise.resolve(data) }) or the component's await res.json() breaks.
• Wrap async renders in act: when rendering triggers state updates (a fetch then setState ), Jest warns unless you await act(async () =>render(...)). act comes from react-dom/test-utils.
• data-testid for counting: tag each card with data-testid="resCard" in the component, then getAllByTestId counts them — assert 20 before search, 4 after. Snapshotting before-and-after proves the filter actually ran.
• Tests run offline: because fetch is faked, the suite needs no network and no browser — it works with Wi-Fi off.

• Hover for docs: in the editor, hovering a matcher like toBeTruthy shows what it does (e.g. it fails on JavaScript's six falsy values). Cheap way to learn the API as you write.