DEV Community

Why you should be using Vue's new Composition API

Andrew Schmelyun on August 27, 2021

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...

Read full post

Micael Nussbaumer • Aug 27 '21

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.

Muhammad Hasnain • Aug 27 '21 • Edited

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.

tq-bit • Aug 27 '21

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.

Micael Nussbaumer • Aug 28 '21 • Edited

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.

Anatoly Bright • Nov 6 '22

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.

Victor Gladkikh • Aug 28 '21

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.

Micael Nussbaumer • Aug 28 '21

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.

Anatoly Bright • Nov 6 '22

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.

Tefoh • Aug 28 '21

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:))

Marc Ziel • Aug 27 '21 • Edited

I know that this post isn't about async/about but I couldn't help it.
You create an async function but don't use await anywhere still working directly with promises. Either make it a normal function or use await:

const sendLike = async () => {
  isDisabled.value = true;
  likes.value++;
  try {                 // ↓ hardcoded postId, yikes
    await fetch('/api/post/1/likes', {
      method: 'POST'
    })
  } catch (e) {
    likes.value--;
  } finally {
    isDisabled.value = false;
  }
}

Also, you should move this function to useLikes.js since it's part of the same feature set.

Alex Merced • Aug 27 '21

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>

Anatoly Bright • Nov 6 '22

Composition API is 10x more code soup than options API.

Paweł Miczka • Aug 31 '21 • Edited

I started using Composition API with TypeScript 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:

<script>
// imports here

export default defineComponent({
   setup() {
      const name = ref('')

      return { name }
   }
})

</script>

to this:

<script setup>
// imports here

const name = ref('')

</script>

Paweł Miczka • Aug 31 '21

You don't need to use Composition API, sure but I think you will :D

artydev • Aug 27 '21

Hy,
For simple apps why bother with frameworks ?
Loot at this simple counter

<html lang="de">
  <head>
  <meta charset="utf-8">
    <title>title</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <script src="https://efpage.de/DML/DML_homepage/lib/DML-min.js"></script>
    <style>
      button {
        background: lightgreen;
        padding: 10px;
        margin: 5px;

      }
    </style>
  </head>
  <body> 
  <script> 

    function Counter () {
        button("inc").onclick = () =>value.innerText = Number(value.innerText)+1
        let value = idiv("0", "font-weight:bold");
        button("dec").onclick = () => value.innerText = Number(value.innerText)-1
    }

    Counter();
    br()
    Counter();

  </script>
  </body>
</html>

You can test it here :

Counter

Arash Mousavi • Aug 28 '21

Dude, the point of this post is about VueJS framework, not writing a counter.

artydev • Aug 29 '21

I agree with you :-)

Chad Smith • Sep 2 '21

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.

Stefano • Aug 25 '22 • Edited

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

Kev Lawton • Aug 29 '21

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.

yoquiale • Aug 31 '21

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.

Paweł Miczka • Aug 31 '21

but you have deal with this which in vue is kinda not the same thing that you would get inside clear JavaScript code

yoquiale • Sep 1 '21 • Edited

I'm ok with dealing with this.

Micael Nussbaumer • Aug 30 '21

Didn't know about that short cut!

Anatoly Bright • Nov 6 '22

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.

WahidN • Aug 31 '21

So this is like React Hooks?

yoquiale • Aug 31 '21

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.

Alex Merced • Aug 28 '21

I agree normally but with the setup attribute it’s a lot cleaner than setting up the setup function in the exported object