Strict configuration objects in Typescript - Time & Space Complexity
We want to understand how the time it takes to check a strict configuration object grows as the object gets bigger.
How does the program's work increase when more settings are added?
Analyze the time complexity of the following code snippet.
function validateConfig(config: Record, schema: Record): boolean {
for (const key in schema) {
if (!(key in config)) return false;
if (typeof config[key] !== schema[key]) return false;
}
return true;
}
This code checks if a config object matches a strict schema by verifying each required key and its type.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each key in the schema object.
- How many times: Once for every key in the schema.
As the number of keys in the schema grows, the number of checks grows at the same pace.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 key checks |
| 100 | About 100 key checks |
| 1000 | About 1000 key checks |
Pattern observation: The work grows directly with the number of keys; doubling keys doubles the checks.
Time Complexity: O(n)
This means the time to validate grows in a straight line with the number of keys in the schema.
[X] Wrong: "Checking each key is constant time no matter how many keys there are."
[OK] Correct: Each key must be checked one by one, so more keys mean more work, not the same amount.
Understanding how validation scales helps you write efficient code and explain your reasoning clearly in interviews.
"What if the schema included nested objects and the validation checked those recursively? How would the time complexity change?"
Practice
What is the main benefit of using strict configuration objects in TypeScript?
Solution
Step 1: Understand strict configuration objects
Strict configs define exactly which keys and types are allowed in an object.Step 2: Identify the main benefit
This strictness helps catch mistakes early, before running the code.Final Answer:
They catch errors early by enforcing exact keys and types. -> Option CQuick Check:
Strict config = early error detection [OK]
- Thinking strict configs improve runtime speed
- Believing strict configs allow any keys
- Confusing strict configs with UI generation
Which of the following is the correct way to declare a strict configuration object type in TypeScript?
interface Config {
host: string;
port: number;
}Solution
Step 1: Check interface requirements
The Config interface requires both 'host' as string and 'port' as number.Step 2: Match object to interface
const config: Config = { host: 'localhost', port: 8080 }; has both keys with correct types, so it matches Config exactly.Final Answer:
const config: Config = { host: 'localhost', port: 8080 }; -> Option AQuick Check:
All required keys with correct types = const config: Config = { host: 'localhost', port: 8080 }; [OK]
- Omitting required keys
- Using wrong types for keys
- Not specifying the type annotation
What will be the output of this TypeScript code?
interface Settings {
debug: boolean;
version: string;
}
const config: Settings = { debug: true, version: '1.0' };
console.log(config.debug, config.version);Solution
Step 1: Check object matches interface
The object has 'debug' as true (boolean) and 'version' as '1.0' (string), matching Settings.Step 2: Understand console.log output
console.log prints the boolean true and string '1.0' without quotes, so output is: true 1.0Final Answer:
true 1.0 -> Option AQuick Check:
Matching keys print their values correctly [OK]
- Expecting quotes around string in console output
- Thinking missing keys cause runtime error
- Confusing type errors with runtime output
Identify the error in this TypeScript code using a strict configuration object:
interface Options {
timeout: number;
verbose: boolean;
}
const opts: Options = { timeout: 5000, verbose: 'yes' };Solution
Step 1: Check property types against interface
'timeout' is number 5000, correct. 'verbose' is string 'yes', but interface requires boolean.Step 2: Identify type mismatch error
Assigning string to boolean property causes a type error.Final Answer:
Property 'verbose' should be a boolean, not a string. -> Option BQuick Check:
Type mismatch on 'verbose' property [OK]
- Ignoring type mismatch errors
- Thinking missing properties cause this error
- Confusing extra properties with wrong types
You want to create a strict configuration object that only allows keys mode (string), retry (number), and enabled (boolean). Which TypeScript type definition ensures no extra keys are allowed?
Solution
Step 1: Understand how to forbid extra keys
Using an index signature with[key: string]: neverforbids any keys not explicitly declared.Step 2: Compare options
interface Config { mode: string; retry: number; enabled: boolean; } allows extra keys implicitly. type Config = { mode: string; retry: number; enabled: boolean; [key: string]: any } allows any extra keys. type Config = { mode?: string; retry?: number; enabled?: boolean } makes keys optional but doesn't forbid extras. Only interface Config { mode: string; retry: number; enabled: boolean; [key: string]: never } forbids extra keys.Final Answer:
interface Config { mode: string; retry: number; enabled: boolean; [key: string]: never } -> Option DQuick Check:
Index signature with never forbids extra keys [OK]
- Thinking interface alone forbids extra keys
- Using any type index signature allowing extras
- Making keys optional but not forbidding extras
Ready to prove it?
Pass the test and this pattern moves unknown
