Path 77 · The type boundary · Intermediate
Check unknown data before trusting its shape.
A guided, practical route through typescript type safety.
What you will be able to do
Create a typed parser for an unknown registration payload and represent success and failure with a discriminated union.
Plan about 9h 2m in total. Reading and practice are editorial estimates; video runtimes come from public provider metadata. Your pace will vary.
Before you begin
Check your starting point
What you need
Basic JavaScript functions and objects. A local Node.js and TypeScript setup is needed for compiler exercises.
The selected public provider lessons are free to view. The original case can be completed with paper, a text editor or freely available local tools. Paid exams, certificates, subscriptions and optional provider software are not required for this project.
Completing this WikiFree path does not award a provider certificate. Any provider assessment, account requirement or credential must be checked separately on its official page.
Three readiness questions
Does as Registration validate JSON?
No. A type assertion does not add runtime checks.
Why start external data as unknown?
It requires narrowing before use.
What can a discriminant do?
Let branches safely distinguish success from failure.
Use a workable pace
At 5 hours per week, allow about 2 weeks. Start with Stage 1, continue in order and reserve 2h 30m for the capstone. If a gate fails, use its repair step before advancing. At another weekly budget, divide 542 estimated minutes by your available weekly minutes and round up.
Keep a small evidence folder. A checked box means you reviewed your output; it is not a certificate or proof that a provider lesson was watched.
The working case
Unknown input becomes a checked result
A fictional registration endpoint receives unknown JSON values. A valid payload has a nonblank string name and an integer seats value from 1 to 4. Type assertions alone cannot validate incoming runtime data. The local exercise sends nothing to a server.
| Payload | Expected result |
|---|---|
| {"name":"Ada","seats":2} | valid |
| {"name":"Ben","seats":"2"} | invalid: string seats |
| {"name":"","seats":1} | invalid: blank name |
| null | invalid: not object |
The table and explanations preserve the essential case information when the diagram is unavailable.
Your route
Five outputs, then a final handoff
- 01Distinguish static and runtime checksType definitions
About 1h 31m including assigned learning and practice. - 02Narrow the input safelyBoundary parser
About 1h 30m including assigned learning and practice. - 03Use the result exhaustivelyTyped consumer
About 1h 16m including assigned learning and practice. - 04Test boundaries and compilationCompile and runtime evidence
About 1h 25m including assigned learning and practice. - 05Document the contractParser handoff
About 50m including assigned learning and practice. - FINALCapstone reviewCombine the evidence into one inspectable handoff.
About 2h 30m.
0 of 6 outputs checked. JavaScript adds browser-only progress saving.
The complete lesson and all downloads remain available. Use the printable project workbook to track your progress.
Use the minimum useful source material
The courses behind this route
Simplilearn
Free Simplilearn Course: TypeScript for Web and Node.js Development
The published TypeScript introduction and generics lessons provide foundations; current official narrowing documentation supplements runtime-boundary details.
Selected material only; this path does not claim completion of the entire provider course.
Course publication and selected public lesson metadata were checked on 13 October 2026. This is not a claim of full video playback, provider-course completion or permanent availability. Recheck the linked source if a lesson changes.
Learn, make, inspect
The five-stage workshop
Distinguish static and runtime checks
Video 25m · reading budget 0m · original practice about 1h 5m.
TypeScript can detect inconsistencies in typed code, but external input still arrives at runtime. Treat parsed JSON as unknown and validate the properties you need. Do not use any to silence a boundary problem. This case is deliberately small so the relationship between checks and returned types is visible.
Watch these selected lessons
Do the work
Define Registration and ParseResult without using any.
Save this output
Type definitions
Pass the review gate
Success and failure branches have different explicit discriminants.
If you need another attempt
Replace an unchecked cast with a runtime condition.
Narrow the input safely
Video 0m · reading budget 0m · original practice about 1h 30m.
Check for a non-null object before accessing properties. Then validate each property’s type and allowed range. Arrays are objects too, so explicitly reject them for this contract. Return a structured error instead of throwing for routine invalid input, and avoid including sensitive raw payloads in messages.
Original application stage. Use your preceding outputs and the supplied case; there is no additional required provider lesson.
Do the work
Implement parseRegistration(value: unknown).
Save this output
Boundary parser
Pass the review gate
All four supplied cases return the expected branch without crashing.
If you need another attempt
Test null and arrays before property access.
Use the result exhaustively
Video 11m · reading budget 0m · original practice about 1h 5m.
A discriminated union lets callers use validated data only in the success branch. A reusable result type can express the same pattern across parsers without weakening the boundary. Keep generics focused on a real repeated relationship; extra abstraction is not automatically safer or clearer.
Watch these selected lessons
Do the work
Write a consumer that formats valid seats and displays an error otherwise.
Save this output
Typed consumer
Pass the review gate
The compiler rejects access to data in the failure branch.
If you need another attempt
Narrow on the discriminant before reading branch-specific fields.
Test boundaries and compilation
Video 0m · reading budget 0m · original practice about 1h 25m.
Compiler checks and runtime tests answer different questions. Run strict compilation and execute cases for zero, one, four, five, fractional seats, arrays and null. Record the actual toolchain used. A passing compiler alone does not prove that malformed JSON is refused.
Original application stage. Use your preceding outputs and the supplied case; there is no additional required provider lesson.
Do the work
Run the supplied checks and add a missing-property case.
Save this output
Compile and runtime evidence
Pass the review gate
Boundary values 1 and 4 pass; out-of-range and non-integer values fail.
If you need another attempt
Name the expected runtime result separately from the expected compiler result.
Document the contract
Video 0m · reading budget 0m · original practice about 50m.
A parser contract should explain normalization, ignored properties and error behavior. This case trims the name and accepts only the two validated fields in the returned value. Extra input properties are ignored rather than copied. State that this is validation for a local example, not complete API security.
Original application stage. Use your preceding outputs and the supplied case; there is no additional required provider lesson.
Do the work
Write the input contract and an example caller.
Save this output
Parser handoff
Pass the review gate
The returned object does not blindly spread unknown input fields.
If you need another attempt
Construct the validated output explicitly.
Make the result inspectable
Your final project
Deliver types, parser, consumer, strict compiler settings, runtime cases and README. Include one intentionally invalid caller in a separate compile-fail example and explain the error.
The ZIP includes synthetic input data, a project workbook, worked reference, evidence log, scoring rubric and case-specific materials. Code projects include source and clearly stated local execution requirements.
Use one consistent rubric
| Criterion | Maximum | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The critical condition
No unchecked assertion or any bypasses the external-data boundary.
Compare with a worked reference
The string "2" is rejected rather than coerced. A valid input {name:" Ada ", seats:2} becomes {name:"Ada", seats:2}. null and arrays fail the object contract. A success result exposes data; a failure exposes an error and no data field.
Know the boundary
This is a local type-and-validation exercise, not authentication, authorization or a deployed API.
Questions before you finish
Do I need to finish every source course?
No. This path names selected lessons or reading sections. Complete the full provider course only if it supports your wider goal. The path does not claim equivalence to that course.
How do I know when to advance?
Use the output and review gate in each stage. If evidence is missing or a result conflicts with the case, follow the repair step and retry before advancing.
Can I do the project without paid software?
The selected public provider lessons are free to view. The original case can be completed with paper, a text editor or freely available local tools. Paid exams, certificates, subscriptions and optional provider software are not required for this project.
What does my checklist prove?
It records your own review in this browser only. It does not verify viewing, skill, a provider credential or a real-world deployment.
What if a lesson or tool changes?
Use the linked course and provider page to inspect current availability. Record the change and revisit the relevant assignment; do not invent a replacement lesson or claim an unavailable activity was completed.
Questions & discussion
Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.