Vue 3 Composables vs Vue 2 Mixins: differences and problems solved
Tests why Vue replaced mixins with composables for stateful logic reuse. Answers cite property collisions, unclear origin, inflexible config, and weak type inference.
What's really being asked
This question probes whether you understand the architectural motivation behind Vue 3's Composition API. It is not enough to know the API surface; the interviewer wants to see that you grasp why mixins created maintenance nightmares in large Vue 2 codebases and how composables specifically address those root causes.
The full answer
First, name the four core mixin problems explicitly. Property collisions occur because mixins merge their options into the component namespace, so two mixins defining the same data key or method silently overwrite each other or rely on obscure merge strategies. Unclear source means a developer reading a component cannot tell whether a given property came from a mixin, another mixin, or the component itself without inspecting every source file. Configuration inflexibility happens because mixins share state through merged options rather than function arguments, making it hard to customize behavior per instance. Poor type inference stems from the Options API's reliance on this context, which TypeScript struggles to type accurately across mixin boundaries. Second, map each problem to the composable solution. Composables use explicit imports and return values, so every piece of state is visible in the setup function where it is consumed. They accept function parameters for configuration, making reuse flexible. Because they are plain functions using refs and lifecycle hooks, TypeScript can infer types cleanly through return objects.
The mistakes people make
Calling composables just syntactic sugar or a style preference. Claiming mixins are deprecated in Vue 2; they are not, but Vue 3 actively discourages them. Describing composables as only for small utilities while insisting mixins still work for large features; this misses the scalability argument. Failing to mention the diamond problem where multiple mixins depend on the same base mixin, causing duplicate state or conflicting merges.
What usually comes next
How would you migrate an existing mixin to a composable? When is it acceptable to still use a mixin in a Vue 3 codebase? How do you test a composable compared to testing a mixin? How do composables interact with the Options API in legacy components?
A concrete example
Imagine a useMouse composable versus a mouseTracker mixin. The mixin injects x and y data properties directly into the component, so if another mixin also provides x, one overwrites the other and the template breaks mysteriously. The composable returns x and y explicitly in the setup function of each component, so naming conflicts are resolved by destructuring or renaming at the call site, and the reader sees exactly where the state originates.
Interview question
In a Vue 2 component using multiple mixins, a fetchData method from one mixin silently overwrites another. Which trait of Vue 3 composables prevents this?
- a.Vue 3 deprecates mixins and emits runtime warnings when method collisions occur
- b.They accept configuration via function arguments instead of merged options
- c.Their returned values are explicitly destructured and can be renamed at the call siteCorrect
- d.They are pure functions that do not expose methods to the component instance
Why? this is the answer
B is correct because explicit returns let developers rename bindings at the call site, making conflicts visible and resolvable. A describes a different composable benefit—configuration flexibility—rather than collision avoidance.
Just read this? Test yourself on what you have been reading.
Read the original → vuejs.org
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 vue — each one lists the topics its interview covers.
See open roles