Primary mechanism for passing data from parent to child component
Tests unidirectional parent-to-child data flow and explicit component contracts. A strong answer names props or inputs, explains one-way binding, and warns against direct child mutation. Red flag: confusing props with global state or events.
WHAT THIS TESTS: Whether the candidate understands the fundamental parent-to-child communication pattern in modern component frameworks. At the senior level, interviewers care less about syntax memorization and more about whether the engineer recognizes unidirectional data flow, explicit contracts, and the separation of concerns between data ownership and consumption. The question also surfaces whether the candidate conflates local state with external inputs, understands why direct mutation breaks predictability, and can articulate the boundary between a component's public interface and its internal implementation.
A GOOD ANSWER COVERS: First, naming the mechanism explicitly, such as Vue props, Angular Input decorators, or Svelte exported props. Second, describing the direction of flow, specifically that data moves downward from owner to consumer through template attributes or bindings. Third, explaining the contract, meaning the child declares what it accepts and the parent fulfills that contract. Fourth, emphasizing immutability, noting that the child should treat received data as read-only and notify the parent via events or callbacks when changes are needed. Fifth, mentioning framework specifics only to illustrate the concept rather than to recite documentation verbatim. A senior candidate might also contrast this with anti-patterns like deep prop drilling without context or using global state to avoid simple parent-child wiring.
COMMON WRONG ANSWERS: Claiming that props are two-way bound by default or that the child can directly mutate the parent's variable. Using vague terms like "you pass it down" without explaining the declaration contract on the child side. Confusing props with provide or inject patterns, global stores, or service-based state. For Vue specifically, a red flag is describing only the Options API props array without acknowledging the validation and type benefits of object syntax or the TypeScript defineProps macro. Another red flag is suggesting v-model on a prop without explaining the event emission and update pattern that makes it work.
LIKELY FOLLOW-UPS: How would you handle deep mutations in a prop if the parent object must change? When would you use provide or inject instead of props? How do you validate prop types in Vue or handle default values and required flags? What happens if a prop name conflicts with a native HTML attribute or an existing DOM property? How does Svelte's export let differ from standard module exports, and how does Angular's change detection interact with Input references versus primitive values?
ONE CONCRETE EXAMPLE: In Vue 3 with script setup, a parent passes a title to a child by writing ChildComponent title="Hello" or dynamically with a colon prefix in the template. The child declares defineProps({ title: String }) to accept it and optionally provide a default. Inside the child, the title is accessed via props.title or destructured with compiler-assisted reactivity in Vue 3.5 and above. If the child needs to change the title, it emits an event with defineEmits and the parent listens with v-on to update its own local state, preserving the one-way flow and making data ownership transparent.
Read the original → vuejs.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.