TypeScript skill practice
How do you approach this?Find TypeScript Logic Flaws Before Shipping
Published
Quick answer
Find a TypeScript flaw by testing the behavior promised by a function at the points where a type narrows, a value becomes optional, or an assertion bypasses evidence. Types can make impossible states harder to express, but they cannot automatically choose the right fallback, distinguish an empty value from absence, or validate data from outside the program. Trace concrete cases through the code and its declared shape together.
Treat falsy values as domain values
A TypeScript type may permit zero, false, or an empty string, yet a truthiness branch can still discard them. List the valid values of the domain and check whether the condition asks 'is present' or accidentally asks 'is truthy,' then verify the chosen behavior in a focused test.
Inspect assertions as review hotspots
The as keyword and non-null assertion can be appropriate when earlier code has established an invariant, but they deserve an evidence trail. Find the branch, validator, or constructor that guarantees the claim; if it is missing, the assertion may be converting a real error into a later surprise.
Original example
Do not confuse a present result with a truthy result
type Result = { value: number } | undefined;
function readValue(result: Result) {
if (result?.value) return result.value;
return 100;
}In this original TypeScript example, value zero is a valid number but the condition treats it like no result. The useful review move is to state the caller's contract for zero and absence separately, then choose and test an explicit condition that matches that contract rather than relying on type names or concise syntax.
Checklist
- Which valid TypeScript values are falsy at runtime?
- What evidence makes this assertion or non-null access safe?
- Does the fallback preserve the caller's documented meaning?
Practice loop
- 01List the valid falsy values for the TypeScript parameter or result you are reviewing.
- 02Trace one absent value and one valid empty value through the branch conditions.
- 03Find the evidence that justifies each assertion or replace it with a narrow testable guard.
Limits of this page
Static types reduce some mistakes but do not encode all business rules, runtime data quality, or configuration constraints. A short review exercise cannot tell why a particular branch was missed or whether the codebase's existing assertions reflect deliberate compatibility work.
Source context
Editorially reviewed for Unrust using public language documentation, common code-review practice, and small original examples written for this resource system.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnostic