Problem Solving

In plain JavaScript you often discover a function’s shape while writing its body — what it takes, what it returns, is decided as you go. In TypeScript, write the signature first: the parameter types and the return type, with no implementation yet. This forces the hard questions — what exactly comes in, what exactly goes out, what happens on the empty case — before a single line of logic exists, the same discipline Module 12’s "pin the contract" step taught, now enforced by the compiler instead of by memory.

1. 1
   Name it and write the signature only

   function groupByLength(words: string[]): Map<number, string[]> { throw new Error("todo") } — no body yet. Just naming the input and output types surfaces the first decision: a Map, or a plain object? Ordered by length, or grouped?

2. 2
   Read the signature back as a sentence

   "Given an array of strings, return a map from word length to the words of that length." If that sentence does not match what you meant, the signature was wrong before you wrote any logic to get wrong.

3. 3
   Fill in the body — the types now constrain every line

   The return type Map<number, string[]> means the compiler flags it immediately if you accidentally return {} or forget a return on one branch. The signature is doing the work a comment used to do, except it cannot go stale.

Two pointers walk from both ends (or two speeds) of sorted data, moving one pointer based on a comparison — O(n) instead of O(n²). The words that give it away: "pair that sums to", "in a sorted array", "from both ends". A typed version is worth writing precisely because the return shape — a tuple, or null for "not found" — is exactly the kind of thing worth pinning down first.

A sliding window is a contiguous range that expands and shrinks, so each element enters and leaves the window once — O(n) instead of re-scanning. A fixed-size window (sum of every k-length slice) needs only numbers; a variable window that tracks "have I seen this character before, and where" needs a typed Map<string, number> — the key is the character, the value is the last index it was seen at.

A lot of real UI and network code is "one of a fixed set of states, each carrying different data" — a request that is idle, loading, succeeded with data, or failed with a message. Modelling this as a discriminated union — a union of object types sharing one literal-typed kind field — means a switch on kind narrows the type inside each case, so state.data is only reachable where state.kind === "success" actually holds.

This is the walk every real codebase takes. A small, working, untyped JavaScript function — a shopping-cart total — gets renamed .js to .ts, and tsc immediately has opinions. Each error below is exactly what a migration surfaces, in the order it surfaces, ending with the fully typed version.

// cart.js — works fine, no types anywhere
function calculateTotal(items, discount) {
  let total = 0
  for (const item of items) {
    total += item.price * item.qty
  }
  if (discount) {
    total = total - total * discount.rate
  }
  return total
}

const cart = [
  { name: "Keyboard", price: 80, qty: 1 },
  { name: "Mouse", price: 25, qty: 2 },
]

console.log(calculateTotal(cart, { rate: 0.25 }))

Step 1: rename to cart.ts and change nothing else. With strict on, tsc refuses before it even reaches the logic.

function calculateTotal(items, discount) {
  let total = 0
  for (const item of items) {

cart.ts:1:26 - error TS7006: Parameter 'items' implicitly has an 'any' type.

1 function calculateTotal(items, discount) {
                           ~~~~~

cart.ts:1:33 - error TS7006: Parameter 'discount' implicitly has an 'any' type.

1 function calculateTotal(items, discount) {
                                  ~~~~~~~~

interface CartItem {
  name: string
  price: number
  quantity: number
}

interface Discount {
  rate: number
}

function calculateTotal(items: CartItem[], discount?: Discount) {
  // body unchanged for now
}

Step 2: the interface above was typed from memory, and the field was named quantity. The function body — still unchanged from the original JS — reads item.qty.

function calculateTotal(items: CartItem[], discount?: Discount) {
  let total = 0
  for (const item of items) {
    total += item.price * item.qty
  }

cart.ts:14:24 - error TS2339: Property 'qty' does not exist on type 'CartItem'. Did you mean 'quantity'?

14     total += item.price * item.qty
                            ~~~~~~~~

interface CartItem {
  name: string
  price: number
  qty: number
}

Step 3: the interface and the body now agree. The last error appears at the call site, where a caller passes a discount that looks reasonable but is not the shape Discount declares.

console.log(calculateTotal(cart, { rate: "25%" }))

cart.ts:22:38 - error TS2322: Type 'string' is not assignable to type 'number'.

22 console.log(calculateTotal(cart, { rate: "25%" }))
                                        ~~~~

console.log(calculateTotal(cart, { rate: 0.25 }))

All three errors fixed, the fully migrated file: two named interfaces, typed parameters, an explicit return type, and the call sites matching what the types promise.