I don't really agree with the arguments put forward for the new API. Setting aside that I think that, that declarative way with well understood and defined properties was one of the strengths of vue along with automatic reactivity based on data and computed properties.
In the like button you go from something that has explicitly defined and named things (mounted, data, methods and computed properties) to a soup. I need to read it all every single time because everything it exports can be just about anything.
In terms of sharing functions there wasn't anything before preventing you from writing your functions in files outside, importing them in the vue component and wrapping them in methods to be used inside the templates (import { fun_x } from "Y", methods: { fun_x(args) { return fun_x(args) }} and then using this.fun_x or fun_x from a template).
Don't know if in the internal parts of vue it helps or not the development/work and optimization of the framework, but from my point of view as a user of the framework, it seems like a step back, motivated by FOMO on React. Besides, when you extract those things into a useLikes it's even worse than mixins, for all the criticism their usage had, at least it was structured.
With version 3.x vue team probably want to use hooks inside vue, and they come with composition api. and for some reasons it didnt work perfect. with version 3.2 they try Svelte syntax, how ever in my opinion its getting better but it wasnt a good start.
And i really excited for new $ref api for next version, its gonna be better(hopefully:))
Those examples are very very simple. I have worked on quite a big Vue app. Some pages became very very repetitive, and there is no way to remove this other than use mixins. And mixing are evil.
On other project we started from scratch with Vue3 and composition api. It's much easier to work with. You don't need to scroll across document to find data section or computed values. All required parts can be placed together.
The problem is not in options API, but in the general architecture, if you have repetitive components, it just means that components have to be a single one with some options, or some basic components and some that extend them. I have quite large Vue 2 projects and never had problems like this. Actually this is why I prefer Vue over React. With composition API there is no point in Vue at all, it becomes not much different from React.
Exactly what I wanted to say! They are turning Vue into React. At least, the syntax is that of React. Vue was already really confusion with registering components in the air or using external libraries, now it's even more confusion with ref(), this.$refs and ref attribute.
You're also right about moving all the code to a setup method and turn it into soup. What about components that may hold code that are more than hundred lines long. This makes searching much more of a challenge.
I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
What you say is somewhat true. Then again, you can keep writing Vue as before. There'll just be another way of doing it.
I only really grasped the usability of Vue's composition API after starting to learn React Hooks (took me a while, as I highly prefer Vue). If you find the composition fucntions to be a soup - they are, but so is a huge component that uses the options API. Imagine a single file that at some point was meant to do a single thing grow to around 600 lines of code, you might consider moving some code out of it. double that amount and you end up with an unmaintainble mess.
Also, consider state. Composition API permits you to relatively simply create a data provider without using third party packages. Especially (async) actions are candidates to be reused in several components.
Wrapping up, for small projects, you're probably well set to develop Vue apps like before. Frankly speaking, I highly prefer the 'common' way, but would not want to close my eyes in front of new innovations, even if they look alien at first.
Another way of doing it means a total mess in documentation and third party code.
Vue 3 already created a havoc in Vue packages, things are just not compatible. Still even now I start all new projects on Vue 2 and Nuxt 2, cause Nuxt 3 is not production ready. Nuxt 3 had 100 times less downloads, means everyone just sticks to Nuxt 2.
If you find a component with 600 lines of code it just means that it has to be split into smaller components, I had quite large projects and never had to write any large component, everything can be split to smaller components and this makes more sense.
To each their own, I mean it's opinions. I've written a few serious apps with React and some quite complex with vue2, I would use vue2 anytime. If you never had "complex" behaviour become a mess of useEffects, contextProviders and friends, that's ok. I use functional languages for everything else, and to be honest, describing UI's in the browser - given the html/dom model and the existing browser apis - is probably one of the few things I think an object oriented wrapper has benefits. I want hooks for the lifecycle, I want to specify reactive data, methods and data that is reactive but also reacts to any of its automatically tracked dependencies (computed properties). For me that organisation makes sense, the same way single file components make sense even if you extract things out of them to "clean up", but that's just my point of view.
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 don't really agree with the arguments put forward for the new API. Setting aside that I think that, that declarative way with well understood and defined properties was one of the strengths of vue along with automatic reactivity based on
dataandcomputedproperties.In the
like buttonyou go from something that has explicitly defined and named things (mounted,data,methodsandcomputed properties) to a soup. I need to read it all every single time because everything it exports can be just about anything.In terms of sharing functions there wasn't anything before preventing you from writing your functions in files outside, importing them in the vue component and wrapping them in methods to be used inside the templates (
import { fun_x } from "Y",methods: { fun_x(args) { return fun_x(args) }}and then usingthis.fun_xorfun_xfrom a template).Don't know if in the internal parts of vue it helps or not the development/work and optimization of the framework, but from my point of view as a user of the framework, it seems like a step back, motivated by FOMO on React. Besides, when you extract those things into a
useLikesit's even worse thanmixins, for all the criticism their usage had, at least it was structured.With version 3.x vue team probably want to use hooks inside vue, and they come with composition api. and for some reasons it didnt work perfect. with version 3.2 they try Svelte syntax, how ever in my opinion its getting better but it wasnt a good start.
And i really excited for new $ref api for next version, its gonna be better(hopefully:))
Those examples are very very simple. I have worked on quite a big Vue app. Some pages became very very repetitive, and there is no way to remove this other than use mixins. And mixing are evil.
On other project we started from scratch with Vue3 and composition api. It's much easier to work with. You don't need to scroll across document to find data section or computed values. All required parts can be placed together.
The problem is not in options API, but in the general architecture, if you have repetitive components, it just means that components have to be a single one with some options, or some basic components and some that extend them. I have quite large Vue 2 projects and never had problems like this. Actually this is why I prefer Vue over React. With composition API there is no point in Vue at all, it becomes not much different from React.
Why is mixing evil? You could create:
my_mixin_only_for_my_component_because_i_dont_like_scrolling_and_prefer_opening_another_file.jsand mix it in.But these are all just opinions of course. Having worked with very complex ui's both in vue and react I still prefer vue2's way of organising code.
Exactly what I wanted to say! They are turning Vue into React. At least, the syntax is that of React. Vue was already really confusion with registering components in the air or using external libraries, now it's even more confusion with ref(), this.$refs and ref attribute.
You're also right about moving all the code to a setup method and turn it into soup. What about components that may hold code that are more than hundred lines long. This makes searching much more of a challenge.
What you say is somewhat true. Then again, you can keep writing Vue as before. There'll just be another way of doing it.
I only really grasped the usability of Vue's composition API after starting to learn React Hooks (took me a while, as I highly prefer Vue). If you find the composition fucntions to be a soup - they are, but so is a huge component that uses the options API. Imagine a single file that at some point was meant to do a single thing grow to around 600 lines of code, you might consider moving some code out of it. double that amount and you end up with an unmaintainble mess.
Also, consider state. Composition API permits you to relatively simply create a data provider without using third party packages. Especially (async) actions are candidates to be reused in several components.
Wrapping up, for small projects, you're probably well set to develop Vue apps like before. Frankly speaking, I highly prefer the 'common' way, but would not want to close my eyes in front of new innovations, even if they look alien at first.
Another way of doing it means a total mess in documentation and third party code.
Vue 3 already created a havoc in Vue packages, things are just not compatible. Still even now I start all new projects on Vue 2 and Nuxt 2, cause Nuxt 3 is not production ready. Nuxt 3 had 100 times less downloads, means everyone just sticks to Nuxt 2.
If you find a component with 600 lines of code it just means that it has to be split into smaller components, I had quite large projects and never had to write any large component, everything can be split to smaller components and this makes more sense.
To each their own, I mean it's opinions. I've written a few serious apps with React and some quite complex with vue2, I would use vue2 anytime. If you never had "complex" behaviour become a mess of
useEffects,contextProvidersand friends, that's ok. I use functional languages for everything else, and to be honest, describing UI's in the browser - given the html/dom model and the existing browser apis - is probably one of the few things I think an object oriented wrapper has benefits. I want hooks for the lifecycle, I want to specify reactive data, methods and data that is reactive but also reacts to any of its automatically tracked dependencies (computed properties). For me that organisation makes sense, the same way single file components make sense even if you extract things out of them to "clean up", but that's just my point of view.