FE7: The modern frontend toolkit
TypeScript for components and data
🎯You'll be able to
Type props and data with TypeScript so mistakes show up before the page runs.
🏠The everyday picture
A railway reservation form has fixed boxes: a 10-digit PNR, a date, a number of passengers. The clerk can reject a wrong entry before the ticket is printed. TypeScript checks your code's "boxes" before it runs.
📘What it really is
-
TypeScript adds types to JavaScript and checks them while you write and build. Many mistakes (a misspelt property, a missing argument, a value that might be
undefined) are caught before users see them. -
Type component props:
type ProductCardProps = {
product: { id: string; name: string; pricePaise: number; inStock: boolean };
onAdd: (id: string) => void;
};
-
Type API responses, but remember that types vanish at runtime: the server can still send something unexpected. For data from outside, validate at runtime with a schema library such as Zod, and derive the type from the schema.
-
Turn on
strictmode intsconfig.jsonsonullandundefinedare checked. - Avoid
any: it switches checking off. Useunknownand narrow it, or write the real type. - Union types model real states:
type Order = { status: 'placed' } | { status: 'out_for_delivery'; riderPhone: string }.
📝A worked example
Kirana's API sometimes returned price as a string ("120.00") for older products. In plain JavaScript, price * qty worked by
accident, but price + deliveryFee produced "120.0030".
const Product = z.object({
id: z.string(),
name: z.string(),
pricePaise: z.number().int().nonnegative(),
});
type Product = z.infer<typeof Product>;
const products = z.array(Product).parse(await res.json()); // fails loudly on bad data
The schema caught 14 products with string prices on the first run. The backend team fixed them, and the cart bug didn't return.
🌍Where it's used
- Most professional React and Next.js codebases.
- Shared design systems, where props must be clear to other teams.
- API boundaries, where runtime validation protects the app.
📝Case scenario
A developer silences a TypeScript error with as any to meet a deadline. Two weeks later, orders fail for customers without a saved
address: the code reads user.address.pincode, and address can be missing. Removing the any, handling the missing address with a
clear prompt, and adding a lint rule against any prevents a repeat.
🖱️Try it
Convert your Kirana product card and cart to TypeScript with strict mode. Add a Zod schema for the product API response, feed it one bad product on purpose, and see where it fails.
⚠️Common mistakes
- Using
anyto silence an error. Sign: a bug the types should have caught. Fix: describe the real shape, or useunknownand check it. - Trusting API data matches the type. Sign: a crash on a missing field. Fix: check data at the edge where it enters the app.
🛠️For your project
Run npx tsc --noEmit in the starter kit; Project 2's checklist asks for zero type errors.
✅Quick check
Why validate API data at runtime when you already have TypeScript types?
Show the answer
Types are removed when the code runs, so they can't check what the server actually sends.
What does any do?
Show the answer
It switches off type checking for that value, hiding mistakes.