I have been using Vue for a few years now and have several medium to large projects in production and I have never felt the need for what this change provides. The examples used in the RFC feel like outliers or made to be more common than they actually are.
That's exactly the point. Mixins are the same composition pattern that 3.x API introduces, but with greater problems, for example :
Multiple mixins can clash when using the same properties
global mixins let you use properties and methods without even knowing where they are declared.
You can read more on the rendered RFC, but the point is that there can be quite many improvements that the 3.x API can give to applications, especially if they are big
I have never had an issue where two mixins clash and if so it sounds like a design problem more than a problem with the core API/framework and it should be addressed during dev time.
And the times I have been reviewing a component's logic and saw a prop or method being used and cant find it declared in that component I look in the mixins because thats likely the place its coming from.
Again I don't feel like these are common issues I have come across in the 3 years I have been using Vue professionally but that may just be me.
To be honest I hadn't had a problem either but I've never worked on a massively large Vue app either. Maybe they could have just introduced a different way to alias mixins so that methods had a prefix instead of adding a completely new way of using Vue
@ju66ernaut
It is a design problem, but for example if you have two mixins both fetching a remote API, you need to be extra creative on the isLoading property name to avoid clashing, and check every other mixin to be 100% safe. Another problem is that if you use two third party libraries as mixins and they both declare a property, computed, or method with the same name you are pretty much out of options.
@amcsi
Yes, but with the spread operator you are explicitly merging the keys and somehow take full responsibility of what can potentially clash 😄. With mixins your only option is to rename one of the properties, which can be problematic or even not possible if mixins come from 3rd party libs.
I don't wanna convince you that 3.x API is 100% better than the current, but as you can see the current implementation has some issues that cannot be solved easily
Me too.. I have SSR and Hybrid applications running on Android and iOS, always was able to go around any limitations I found. I haven't even had any issues with typecasting, what am I doing wrong?? hahaha
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have been using Vue for a few years now and have several medium to large projects in production and I have never felt the need for what this change provides. The examples used in the RFC feel like outliers or made to be more common than they actually are.
So you've never used a mixin once on a big project? I really find it hard to believe.
I use mixins all the time. I am not sure what you are referring to. I didn't mention mixins.
That's exactly the point. Mixins are the same composition pattern that 3.x API introduces, but with greater problems, for example :
You can read more on the rendered RFC, but the point is that there can be quite many improvements that the 3.x API can give to applications, especially if they are big
I have never had an issue where two mixins clash and if so it sounds like a design problem more than a problem with the core API/framework and it should be addressed during dev time.
And the times I have been reviewing a component's logic and saw a prop or method being used and cant find it declared in that component I look in the mixins because thats likely the place its coming from.
Again I don't feel like these are common issues I have come across in the 3 years I have been using Vue professionally but that may just be me.
To be honest I hadn't had a problem either but I've never worked on a massively large Vue app either. Maybe they could have just introduced a different way to alias mixins so that methods had a prefix instead of adding a completely new way of using Vue
You can get clashes in the Function API too, if you spread together the return values of several
useXXX()
functions and return them insetup()
.@ju66ernaut It is a design problem, but for example if you have two mixins both fetching a remote API, you need to be extra creative on the
isLoading
property name to avoid clashing, and check every other mixin to be 100% safe. Another problem is that if you use two third party libraries as mixins and they both declare a property, computed, or method with the same name you are pretty much out of options.@amcsi Yes, but with the spread operator you are explicitly merging the keys and somehow take full responsibility of what can potentially clash 😄. With mixins your only option is to rename one of the properties, which can be problematic or even not possible if mixins come from 3rd party libs.
I don't wanna convince you that 3.x API is 100% better than the current, but as you can see the current implementation has some issues that cannot be solved easily
@matteorigon True, my bad.
Me too.. I have SSR and Hybrid applications running on Android and iOS, always was able to go around any limitations I found. I haven't even had any issues with typecasting, what am I doing wrong?? hahaha