You keep hearing about this composition API in Vue. But it's a little scary and intimidating, and why it's so much better isn't really all that cle...
For further actions, you may consider blocking this person and/or reporting abuse
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
andcomputed
properties.In the
like button
you go from something that has explicitly defined and named things (mounted
,data
,methods
andcomputed 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_x
orfun_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 thanmixins
, for all the criticism their usage had, at least it was structured.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.
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
useEffect
s,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.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.
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.
Why is mixing evil? You could create:
my_mixin_only_for_my_component_because_i_dont_like_scrolling_and_prefer_opening_another_file.js
and 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.
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.
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:))
I know that this post isn't about
async/about
but I couldn't help it.You create an
async
function but don't useawait
anywhere still working directly with promises. Either make it a normal function or useawait
:Also, you should move this function to
useLikes.js
since it's part of the same feature set.The composition API is 10x easier to use if you use the experiemental setup attribute.
‘’’
</setup><br> ‘’’</p> <p>In this situation the script tag is the setup function and looks a like cleaner, you can try this in the ‘npm init vite’ Vue template which has this out of the box</p>
Composition API is 10x more code soup than options API.
I started using
Composition API
withTypeScript
last year and damn - that was great experience. Not only because code looks "cooler" and cleaner but also with fact that you can much easier split your code into single "plugins".With this you can move things like
onMounted
etc. to separated files and implement those without any problem to any component you want.There is one great thing that was implemented in 3.2 -
<script setup>
which transforms your code from this:to this:
You don't need to use Composition API, sure but I think you will :D
Hy,
For simple apps why bother with frameworks ?
Loot at this simple counter
You can test it here :
Counter
Dude, the point of this post is about VueJS framework, not writing a counter.
I agree with you :-)
When the composition API was announced I was hesitant, my argument was that most of the dev time would go towards the new composition api. It came out and I tried it, and I’d say it was ok. I’ve written large scale applications with Vue 2. Matter of fact I’m currently working on 3 large scale applications in Vue 2 right now at work. So I’m very familiar with the options API in large applications. To me it’s easier. Large Applications are usually more complex to deal with, with the options API I can go to a component and tell you very quickly where things are, and with a little code review we’ve kept components well maintained and clean still.
My point is this - you can write “spaghetti” code on any language, framework, or pattern. In the end it is up to you, the developer, to keep the codebase clean. I’ve already seen, in my honest opinion, not great code with the new composition API, so I don’t think it fixes any problems. It’s up the developers to actually write it that way to fix it. Which in my experience is possible in both ways.
So it’s not that I have an issue with the Composition API, I just don’t think it fixes the problems people say they fix. In the end cleaner code is up to the developer maintaining the project, not the framework or pattern they use, and is still relatively opinionated.
I still like more Vue 2 than 3 but it also depends of how you implemented the composition api in your project. It is maybe more the way you structured you project and how you abstracted your logic and reused your components
PM / Dev Manager non-web developer here. Looking at Angular vs React vs Vue vs Flutter vs Blazor vs Svelte, I concluded that Vue is superior for my purpose of creating quick internal MVPs. However, much like the debate in the comments, the Vue2 vs Vue3 uncertainty has definitely made me question investing in Vue. I seriously applaud all you front-end web developers building real world solutions on what feels like a constantly shifting "hot mess" of WIP projects and concepts.
Imho options API is better because before I had learnt Vue, knowing what the code would do was clearer than if you use composition API, which introduces ref and I don't know what does that do.
but you have deal with
this
which in vue is kinda not the same thing that you would get inside clear JavaScript codeI'm ok with dealing with this.
Didn't know about that short cut!
I'm completely disagree with the arguments, compositions API doesn't provide any benefits and only creates a messy and unstructured code. I'm sticking to options API even in Vue 3 projects, it just makes more sense, the code is clear and simple and it's so much easier to work especially when multiple developers involved. There is rally no downsides in options API, people that are telling about separating code functionality in a single component making a mistake in the first place where they don't split different functionality to different components. Components in Vue should be small and simple and options API works beautiful with proper architecture.
So this is like React Hooks?
Agree, I liked Vue because of the straightforward templates and because it was easier to understand than React, but now the composition API complicates it and makes it a React wannabe.
I agree normally but with the setup attribute it’s a lot cleaner than setting up the setup function in the exported object