This checkpoint is a small independent task. Budget about twenty minutes: five to plan, ten to implement and check, and five to explain and change the inputs. Close earlier solutions first. A hint is a normal part of learning, but try to name the obstacle before opening it.
Your receipt has a topic, a number of sessions, a duration per session, and a completion flag. These are ordinary JavaScript values. TypeScript helps preserve their roles as you change the program.
Write down the expected message before opening the editor. Decide which variables will change and use let only for those. You may infer obvious local types. For this checkpoint, practise explicit annotations on at least two values too.
After the first successful run, deliberately introduce a type mismatch. Read the compiler message out loud, then restore the program. A passing check and a correct output answer different questions; record evidence for both.
The tiny demonstration below is a reminder, not the completed receipt. Your task uses different data and a full sentence.
Predict, check, then run
Before running, write down the output and explain which information the checker knows. Click Check types first, then Check & run.
const topic: string = "Arrays";
const minutes = 15;
console.log(`${topic}: ${minutes}`);Enable JavaScript to edit and type-check this example.
Check your prediction
Arrays: 15 Acceptance cases before you code
Write a small test plan before implementing typed calculation rather than literal output. These cases extend the brief; they are not a second worked solution. Predict the expected behavior independently, then test through the public function. A good ordinary example and a good boundary example should catch different possible mistakes.
| Case to try | What your result should demonstrate |
|---|---|
| Different session count | Total follows the calculation |
| Zero sessions | Preserve numeric zero and false completion |
| Wrong-type assignment | Checking rejects it without running the program |
After the core task passes, deliberately break one rule and identify the case that notices it. Restore the implementation and explain the failure in terms of the contract, not the number of assertions. If a case requires a concept you have not recalled, revisit the relevant lesson before opening the solution.
Your turn
Checkpoint: Study Receipt: practise
Print Functions: 3 sessions, 60 minutes, done=false. Use topic=“Functions”, sessions=3, minutesPerSession=20 and completed=false; calculate the total instead of typing 60 into the output.
// Plan four values, calculate the total, and format the receipt.Enable JavaScript to edit and type-check this example.
Hint 1: the idea
Keep the numeric calculation separate from the display sentence.
Hint 2: a first step
Declare sessions and minutesPerSession before creating totalMinutes.
Show one solution
const topic: string = "Functions";
const sessions: number = 3;
const minutesPerSession = 20;
const completed = false;
const totalMinutes = sessions * minutesPerSession;
console.log(
`${topic}: ${sessions} sessions, ${totalMinutes} minutes, done=${completed}`
);Enable JavaScript to edit and type-check this example.
Functions: 3 sessions, 60 minutes, done=falseExplain the type of each value and which mistake the checker would catch. Compare your approach before copying this answer.
Change it and explain it
Test zero sessions and a different topic. Would the checker reject negative sessions? Explain why not. Finish by writing a two-sentence explanation of inference and of what the compiler does before JavaScript runs. If you needed the full solution, redo the receipt tomorrow using reading sessions instead.
Completion is saved in this browser only. It does not measure mastery.