Vue.js interview questions

What a strong answer covers

• Define `ref()` as a function that takes an inner value and returns a reactive ref object with a `.value` property, suitable for primitives and objects.
• Define `reactive()` as a function that takes an object and returns a reactive proxy of the original object, making all nested properties reactive.
• Explain that `ref()` is used when you need to make a single primitive value reactive or when you want to pass a reactive object around without losing reactivity on destructuring.
• Explain that `reactive()` is used for making entire objects or arrays reactive, where you expect to work with the object directly and its properties.
• Provide examples: `ref(0)` for a counter, `reactive({ name: 'Alice', age: 30 })` for a user object.

Where people lose the point

• ×Forgetting to access or mutate the `.value` property when working with `ref()` inside the `setup()` function or JavaScript logic.
• ×Attempting to use `reactive()` with primitive values directly, which will not make them reactive.
• ×Destructuring a `reactive()` object directly in `setup()` without using `toRefs()` or `toRef()`, leading to loss of reactivity for the destructured properties.

What a strong answer covers

• Improved organization of logic: Related logic (e.g., feature-specific data, methods, computed properties) can be grouped together, enhancing readability and maintainability, especially in large components.
• Enhanced reusability: Logic can be extracted into reusable 'composables' (functions) that encapsulate stateful logic, promoting a cleaner and more explicit way to share code than mixins.
• Better type inference: The Composition API works very well with TypeScript, providing more robust type inference and better tooling support.
• Increased flexibility: It offers more flexibility in how you structure and compose component logic, leading to more scalable and testable codebases.
• Reduced cognitive overhead for large components: Avoids the 'options sprawl' where a single feature's logic is scattered across multiple options (data, methods, computed, watch).

Where people lose the point

• ×Stating that the Options API is deprecated or no longer supported (it is still fully supported and valid).
• ×Focusing only on the syntax difference without explaining the architectural and maintainability benefits.
• ×Not mentioning composables as a key benefit for logic reuse.

What a strong answer covers

• `onMounted`: Called after the component has been mounted to the DOM. Use it for initial data fetching, direct DOM manipulation (e.g., integrating a third-party library), or setting up event listeners.
• `onUpdated`: Called after the component has updated its DOM tree due to a reactive state change. Use it for performing actions after the DOM has been re-rendered, but be cautious to avoid infinite update loops.
• `onUnmounted`: Called after the component has been unmounted from the DOM. Use it for cleanup tasks, such as removing event listeners, clearing timers, or canceling ongoing network requests to prevent memory leaks.
• Emphasize that these hooks are imported from 'vue' and used within the `setup()` function.

Where people lose the point

• ×Confusing `onMounted` with `onCreated` (which doesn't exist in Composition API, `setup()` serves a similar purpose).
• ×Forgetting to clean up side effects in `onUnmounted`, leading to potential memory leaks.
• ×Using `onUpdated` for every state change, potentially causing performance issues or infinite loops if not handled carefully.

What a strong answer covers

• `computed`: Used for deriving new reactive data based on existing reactive state. It's synchronous, cached, and only re-evaluates when its dependencies change. Ideal for transforming data for display or complex calculations.
• `watch`: Used for performing side effects in response to changes in reactive state. It's asynchronous by default, allows for explicit control over what to watch, and provides access to both new and old values. Ideal for API calls, logging, or imperative DOM manipulations.
• Explain that `computed` properties are primarily for data transformation and should not have side effects.
• Explain that `watch` effects are primarily for side effects and should not return a value that is then used in the template.
• Provide examples: `computed` for `fullName` from `firstName` and `lastName`; `watch` for saving data to local storage when a form field changes.

Where people lose the point

• ×Using `computed` for side effects (e.g., making an API call inside a computed property).
• ×Using `watch` when a simple data transformation is needed, leading to more verbose and less efficient code.
• ×Not understanding that `computed` values are cached, while `watch` effects always run when dependencies change (after initial setup for `watchEffect`).

What a strong answer covers

• Define 'props down': Parent components pass data to child components using props. Props are read-only in the child component, ensuring a unidirectional data flow.
• Define 'events up': Child components communicate changes or events back to their parent components by emitting custom events. The parent component listens for these events.
• Implementation of props: In the child component, declare props using `defineProps()`. In the parent, pass data as attributes to the child component tag.
• Implementation of events: In the child component, declare events using `defineEmits()` and then use the returned `emit` function to trigger events (e.g., `emit('update:modelValue', newValue)`). In the parent, listen using `v-on` (e.g., `@update:modelValue='handler'`).
• Highlight that this pattern promotes clear data flow, makes components more reusable, and simplifies debugging.

Where people lose the point

• ×Attempting to directly mutate a prop received from a parent component in the child component.
• ×Not declaring emitted events using `defineEmits()`, which can lead to warnings or less explicit code.
• ×Confusing `v-model` with a simple prop/emit pair, or not explaining how `v-model` is syntactic sugar for this pattern.

What a strong answer covers

• Define slots: A mechanism for passing content (HTML, components) from a parent component into a child component's template, allowing for more flexible and reusable component design.
• Explain their usefulness: Enable components to be highly customizable, acting as 'layout' components or 'wrapper' components without needing to pass all content as props.
• Describe named slots: Allow a parent to target specific slots within a child component's template by providing a `name` attribute (e.g., `<slot name="header">`). Content is passed using `v-slot:name` or `#name` shorthand.
• Describe scoped slots: Allow the child component to pass data back to the parent's slot content. The parent can then use this data to render the content dynamically (e.g., `<template #default="slotProps">{{ slotProps.item }}</template>`).
• Provide a simple example of a generic `Card` component using a default slot for its body and named slots for header/footer.

Where people lose the point

• ×Confusing slots with props, or thinking slots are only for simple text content.
• ×Not understanding the concept of data flowing from child to parent *within* the slot content for scoped slots.
• ×Incorrectly using the syntax for named or scoped slots (e.g., forgetting `v-slot` or `#`).

What a strong answer covers

• Define navigation guards: Functions that are executed before, during, or after navigation, allowing you to programmatically control or intercept the routing process.
• Explain their purpose: Used for tasks like authentication checks, authorization, data fetching before entering a route, or preventing users from leaving unsaved forms.
• Describe different types: Global guards (`router.beforeEach`), per-route guards (`beforeEnter` in route config), and in-component guards (`beforeRouteEnter`, `beforeRouteUpdate`, `beforeRouteLeave`).
• Provide a common use case: Implementing an authentication guard using `router.beforeEach` to check if a user is logged in before allowing access to protected routes. If not authenticated, redirect to a login page.
• Explain the `to`, `from`, and `next` arguments passed to guards, and how `next()` is used to resolve or redirect navigation.

Where people lose the point

• ×Forgetting to call `next()` in a navigation guard, which will halt navigation indefinitely.
• ×Not understanding the order of execution for different types of guards.
• ×Trying to access `this` inside `beforeRouteEnter` without using the `next(vm => { ... })` callback.

What a strong answer covers

• Core concepts: Pinia stores are defined using `defineStore()`, providing a centralized, reactive state management solution. They are modular by design, allowing for multiple stores.
• Structure: A store typically consists of `state` (a function returning the initial reactive data), `getters` (computed properties for derived state), and `actions` (methods for modifying state, often asynchronously).
• Comparison to Vuex: Pinia is simpler and more lightweight, removing mutations and directly allowing state modification in actions. It has better TypeScript support out-of-the-box and no nested modules by default (stores are flat).
• Explain that Pinia leverages Vue 3's reactivity system directly, making it feel more 'Vue-like' than Vuex.
• Mention that Pinia stores are automatically tree-shakable, meaning only used parts of the store are bundled.

Where people lose the point

• ×Referring to 'mutations' in Pinia (Pinia removes the concept of mutations, state is modified directly in actions).
• ×Not mentioning the improved TypeScript support as a key advantage of Pinia.
• ×Confusing Pinia's modularity with Vuex's nested modules.

What a strong answer covers

• Explain that `v-model` is syntactic sugar for a prop and an emitted event.
• For a basic `v-model` on a custom component, the component must accept a `modelValue` prop and emit an `update:modelValue` event.
• In the child component, declare the `modelValue` prop using `defineProps(['modelValue'])` and the `update:modelValue` event using `defineEmits(['update:modelValue'])`.
• When the internal value changes, the child component calls `emit('update:modelValue', newValue)` to update the parent's bound data.
• For multiple `v-model` bindings on a single component, specify a custom argument for each (e.g., `v-model:title` would expect a `title` prop and `update:title` event).

Where people lose the point

• ×Forgetting to emit the `update:modelValue` event, or emitting it with an incorrect name.
• ×Attempting to directly mutate the `modelValue` prop in the child component.
• ×Not understanding that `v-model` is just a convenient shorthand, not a magical new feature.

What a strong answer covers

• Define `<Teleport>`: A built-in component that allows you to render a component's content into a different part of the DOM, outside of its parent component's hierarchy.
• Explain its primary use case: Useful for managing modals, tooltips, notifications, or other elements that need to be rendered directly under `<body>` or another specific DOM node to avoid CSS stacking context issues, overflow problems, or to ensure they are always on top.
• Describe how it works: It takes a `to` prop, which is a CSS selector or an actual DOM element, specifying the target container where the content should be moved.
• Highlight that the component's logical relationship (props, events, reactivity) with its parent remains intact, even though its rendered DOM position changes.
• Provide an example: Rendering a modal component's content directly to `document.body` to ensure it overlays all other content.

Where people lose the point

• ×Thinking that `<Teleport>` changes the component's logical parent-child relationship or scope.
• ×Not understanding that the content is *moved*, not copied, to the target.
• ×Incorrectly specifying the `to` prop (e.g., using an invalid selector or a non-existent element).

What a strong answer covers

• Define custom directives: A way to encapsulate reusable DOM manipulation logic that can be applied to elements in a declarative manner (e.g., `v-focus`, `v-tooltip`).
• Explain creation: Directives are defined as objects with lifecycle hooks (e.g., `mounted`, `updated`, `unmounted`) that receive the element, binding, and vnode arguments.
• Registration: Directives can be registered globally using `app.directive('my-directive', definition)` or locally within a component using the `directives` option (though less common with Composition API, often registered globally).
• Usage: Apply the directive to an element in the template using `v-my-directive` or `v-my-directive="value"`.
• Provide an example: A `v-focus` directive that automatically focuses an input element when it's mounted, demonstrating the `mounted` hook and `el.focus()`.

Where people lose the point

• ×Confusing directives with components or composables; directives are specifically for low-level DOM manipulation.
• ×Forgetting to register the directive before attempting to use it.
• ×Incorrectly using the arguments passed to directive hooks (e.g., trying to access `binding.value` when no value is provided).

What a strong answer covers

• Define `provide` and `inject`: A pair of functions that allow a parent component (provider) to make data available to any of its descendants (injectors), regardless of how deep the component hierarchy is.
• Explain `provide`: Used in a parent component's `setup()` to make a value available to descendants (e.g., `provide('theme', themeRef)`). The provided value can be reactive.
• Explain `inject`: Used in a descendant component's `setup()` to retrieve a value provided by an ancestor (e.g., `const theme = inject('theme')`). Can also specify a default value.
• Suitable use cases: For 'prop drilling' scenarios where data needs to be passed through many intermediate components that don't directly use the data. Also useful for plugin-like functionality or theme management.
• Contrast with props/events: Avoids prop drilling for deeply nested components. Contrast with Pinia: `provide/inject` is for component-scoped or subtree-scoped state, while Pinia is for global application state.

Where people lose the point

• ×Using `provide/inject` for global application state when Pinia would be more appropriate and maintainable.
• ×Not understanding that `provide/inject` creates a *loose* coupling, making it harder to track data flow than props/events.
• ×Forgetting to make the provided value reactive if it's intended to update descendants.

What a strong answer covers

• Explain `app.config.errorHandler`: A global error handler that can catch errors originating from component renders, event handlers, and lifecycle hooks.
• Describe its usage: Set `app.config.errorHandler` to a function that takes the error, component instance, and info string as arguments. This function can log errors, send them to an error tracking service, or display a user-friendly message.
• Mention `onErrorCaptured`: A component-level hook that can catch errors from descendant components within its own subtree. It can return `false` to stop the error from propagating further up the component tree or to the global handler.
• Discuss asynchronous error handling: Errors in `Promise` rejections (e.g., `async/await` in actions) are not caught by `errorHandler` by default. These need to be handled with `try/catch` blocks or global `unhandledrejection` event listeners.
• Emphasize the importance of robust error handling for user experience and debugging in production.

Where people lose the point

• ×Assuming `app.config.errorHandler` catches all types of errors, especially unhandled promise rejections.
• ×Not distinguishing between global error handling and component-specific error handling (`onErrorCaptured`).
• ×Failing to implement a fallback UI or logging mechanism for caught errors.

What a strong answer covers

• Define SSR: The process of rendering a Vue application on the server and sending the fully rendered HTML to the client. This improves initial load performance, SEO, and user experience.
• Explain hydration: The process where the client-side Vue application 'takes over' the server-rendered HTML. It matches the virtual DOM with the existing DOM, attaches event listeners, and makes the application interactive.
• Benefits of SSR + Hydration: Faster Time-To-Content (TTC) because users see content immediately, better SEO as search engine crawlers see fully rendered pages, and improved perceived performance.
• Challenges: Increased server load, more complex setup, and potential for 'hydration mismatch' errors if the client-side and server-side rendered HTML don't perfectly match.
• Mention frameworks like Nuxt.js that simplify SSR setup for Vue applications.

Where people lose the point

• ×Confusing SSR with static site generation (SSG), though they share some benefits.
• ×Not understanding that hydration is the step where interactivity is added to the static HTML.
• ×Overlooking the potential for hydration errors or increased complexity.

What a strong answer covers

• Define `<KeepAlive>`: A built-in component that allows you to conditionally cache component instances when they are dynamically switched, instead of destroying and recreating them.
• Explain its purpose: It preserves the state and avoids re-rendering of inactive components, leading to better performance and user experience, especially in tabbed interfaces or dynamic component rendering.
• Describe how it works: When a component wrapped by `<KeepAlive>` is deactivated, its instance is cached. When it's reactivated, the cached instance is reused, and its `onActivated` hook is called.
• Scenario: A tabbed interface where each tab contains a complex component (e.g., a data table with filters). Without `<KeepAlive>`, switching tabs would destroy and recreate the component, losing its state and requiring re-fetching data. With `<KeepAlive>`, the component's state is preserved, and switching is instant.
• Mention `include` and `exclude` props for fine-grained control over which components are cached.

Where people lose the point

• ×Thinking `<KeepAlive>` is for all performance optimizations; it's specifically for caching component instances.
• ×Not understanding that `onActivated` and `onDeactivated` hooks are specific to components wrapped by `<KeepAlive>`.
• ×Using `<KeepAlive>` indiscriminately, which can lead to increased memory usage if too many components are cached unnecessarily.