DEV Community


Discussion on: Vue composable - array pagination

dasdaniel profile image
Daniel P Author


In short, the benefits are that with the composition API, you can use multiple functionalities that use same variable names, if there's a collision, you can rename or keep it as part of an object. If you use two or more mixins, you could end up with collisions (like same data variable names intended for internal use being used by both). It is possible to setup multiple mixins, but you also have to setup merge strategies in some cases to prevent unintended interactions (think multiple lifecycle hooks, like each mixin using a created).

In addition the mixins don't do well with our IDE tools. If you use a javascript or typescript class to define a composeable, you can have type definitions for your inputs and outputs. If you're using a mixin, there isn't a way (AFAIK) to have the data, methods, etc. be available for the IDE's intellisense.

I think they also offer better testability. The functions are pure javascript and don't rely on Vue rendering, so you can test without special tools.

I think the arguments for composition over inheritance apply here too.

I will try to do a more thorough writeup of the benefits.

lukaszahradnik profile image
Lukáš Zahradník

Thank you for your reply. I appreciate that you didn't just throw in the argument about composing by option vs logic parts.

I agree with the collisions, merge strategies issues and simpler testability, but I'm not so sure about the IDE support, at least when it comes to TypeScript and class-based components. When extending class with Mixins(MyMixin), IDE recognizes the content of the MyMixin (don't know if it works with JavaScript).

I'm not a big fan of mixins myself, I prefer composing code by logic using components. My main issue with the composition API is that I haven't seen the use case yet, where it would make a big difference using composition API vs current features (components, mixins etc.)