Compile-time vs runtime prop validation across frameworks?
understanding of type safety mechanisms.
TypeScript (compile-time) catches errors before build; Vue props validation (runtime) catches at runtime; tradeoff: TS is stricter, Vue validation is flexible but less safe.
Why it exists
Components are APIs. Callers must pass the right shape and type of data. Typos, wrong types, or missing required fields break things. Type systems (compile-time, runtime, or both) catch these early.
The mental model
Two approaches to validation. Compile-time (TypeScript) checks at build: if you pass the wrong type, tsc fails and you fix before shipping. Runtime (Vue's props validator) checks when the component instantiates: invalid data triggers warnings and may skip rendering. Compile-time is stricter but requires all code to be typed. Runtime is more flexible but misses errors if callers use untyped code (dynamic templates, fetch responses).
How it works
In TypeScript (Angular, Svelte), declare interface Props { name: string; count: number; }. Assign it to the component's generic or class fields. tsc verifies all calls pass matching types. Vue allows both: you can write setup(props: { name: string }) for TS checking, or use props: { name: String, count: { type: Number, required: true, validator: (v) => v > 0 } } for runtime validation. The runtime validator runs when the component receives props; if validation fails, Vue warns (non-breaking). For truly dynamic data (API responses, form inputs), runtime validation is essential because TypeScript doesn't know the shape until runtime.
When it matters
Large teams and refactor-heavy codebases benefit from compile-time type safety; it prevents regressions across 100+ call sites. Smaller projects or highly dynamic code (user-generated, API-driven) may favor runtime validation for flexibility. Production apps often combine both: strict TS in framework code, validators for external/untrusted data.
A concrete example
A UserCard component. TypeScript: interface Props { user: { id: number; name: string; avatar: string } }; calling code must pass that shape or tsc fails. Vue runtime validator: props: { user: { type: Object, validator: (obj) => obj.id && obj.name && obj.avatar } }; if caller passes { id, name } (missing avatar), Vue warns but doesn't break. Blend: use TS for caller type-checking, add runtime validator as a safety net for edge cases.
Interview question
Your Vue component receives a user prop from a server API response. Which approach best validates that the response shape is correct?
- a.Runtime validator function in the props definition
- b.Both TypeScript interface and a runtime validatorCorrect
- c.TypeScript interface on the prop
- d.No validation; trust the API
Why? this is the answer
TypeScript validates at build time (your component code), but the API response is dynamic and may not conform. A runtime validator catches malformed responses at runtime (Option B). Option C alone won't catch API schema drift. Option D is risky. Option A alone is verbose without TS clarity.
Just read this? Test yourself on what you have been reading.
Read the original → vuejs.org
- #typescript
- #prop-validation
- #component-apis
- #type-safety
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles