What if your code could tell you mistakes before running? Parameter type annotations make that happen!
Why Parameter type annotations in Typescript? - Purpose & Use Cases
Imagine you are writing a function that adds two numbers, but you forget to check what kind of values are passed in. Sometimes someone sends a number, sometimes a word, or even nothing at all.
Without clear instructions, your function might break or give wrong answers.
Manually checking each input inside the function is slow and messy. You have to write extra code to test types every time.
This makes your code longer, harder to read, and easy to make mistakes.
Parameter type annotations let you tell the computer exactly what kind of values your function expects.
This way, errors are caught early, and your code stays clean and clear.
function add(a, b) {
return a + b;
}function add(a: number, b: number): number {
return a + b;
}It makes your code safer and easier to understand by clearly defining what inputs are allowed.
Think of ordering a pizza: if you say exactly what size and toppings you want, the kitchen gets it right every time. Parameter type annotations are like giving clear pizza orders to your code.
Parameter type annotations specify the expected input types.
They prevent bugs by catching wrong inputs early.
They make your code easier to read and maintain.
Practice
What does a parameter type annotation in TypeScript do?
Solution
Step 1: Understand the purpose of parameter type annotations
Parameter type annotations specify the expected data type for each function parameter.Step 2: Identify what this means for the function
This helps the programmer and the TypeScript compiler catch errors if wrong data types are used.Final Answer:
It tells what kind of data a function expects for its parameters. -> Option AQuick Check:
Parameter type annotation = tells expected data type [OK]
- Thinking it changes the function's return type
- Believing it runs the function automatically
- Confusing it with removing parameters
Which of the following is the correct way to add a type annotation for a parameter named age that should be a number?
function checkAge(____) { return age > 18; }Solution
Step 1: Recall TypeScript parameter syntax
In TypeScript, the parameter name is followed by a colon and then the type.Step 2: Match the syntax to the options
Only age: number uses the correct syntax:age: number.Final Answer:
age: number -> Option BQuick Check:
Parameter name : type = correct syntax [OK]
- Putting type before parameter name
- Using equals sign instead of colon
- Using hyphen instead of colon
What will be the output of this TypeScript code?
function greet(name: string) { return `Hello, ${name}!`; }
console.log(greet(42));Solution
Step 1: Check the parameter type annotation
The function expects astringparameter namedname.Step 2: Analyze the argument passed
The argument passed is a number42, which does not match the expectedstringtype.Final Answer:
Type error at compile time -> Option AQuick Check:
Passing wrong type causes compile-time error [OK]
- Thinking it prints 'Hello, 42!' anyway
- Expecting a runtime error instead of compile-time
- Assuming undefined is printed
Identify the error in this TypeScript function and choose the fix:
function multiply(x: number, y) { return x * y; }Solution
Step 1: Check parameter annotations
Parameterxhas a typenumber, butyhas no type annotation.Step 2: Understand TypeScript's requirement
All parameters should have type annotations for clarity and type safety.Final Answer:
Add type annotation toy:y: number-> Option CQuick Check:
All parameters need type annotations [OK]
- Leaving some parameters untyped
- Changing unrelated parameter types
- Thinking return type annotation fixes parameter error
You want to write a function formatPrice that takes a price parameter which can be either a number or a string. How should you annotate the parameter to accept both types?
Solution
Step 1: Understand union types in TypeScript
To accept multiple types, use the union operator|between types.Step 2: Apply union type to parameter
Useprice: number | stringto allow either type.Final Answer:
price: number | string -> Option DQuick Check:
Use|for multiple allowed types [OK]
- Using & instead of | for union types
- Using comma-separated types
- Using any which loses type safety
Ready to prove it?
Pass the test and this pattern moves unknown
