Is Vue 3 Composition API Worth It?
Tags: vue, webdev, javascript
Published: 2020-06-22 14:04:55

**The short answer is "yes"**. But I suspect that you are going to need more than a random stranger telling you a one word answer.

There has already been numerous posts and articles talking about the advantages that the Composition API has over the Options API. From the [official RFC](https://composition-api.vuejs.org/#motivation) to this [particular DEV post](https://dev.to/danielelkington/vue-s-darkest-day-3fgh) which also discussed about the controversy behind the Composition API when it was first introduced back in 2019.

I am not, however, going to repeat the points about code reusability, or code organisation (both of which have already been discussed in great lengths in the above links). In this article, I am going to focus more on the development experience.

## Problems with Options API

As someone who also develops in React, I definitely agree that Vue's Options API is much more intuitive and much easier to grasp for a beginner. I mean, `data` for your reactive data, `computed` for data that relies on `data`, `methods` for functions that act on `data`: how much easier can it get? This simplicity was one of the main reason why I gave up on learning React (back when I first started!), and decided to try Vue, and the rest is history.

However, as we all know, the Options API forces us to use the `this` keyword, and prepending everything with the `this` keyword leads to various caveats and problems.

### Poor Type Inference

Firstly, the IDE (or at least VSC, in my case, which is my daily driver) is unable to infer the type of the variable declared. Take for example, this simple case:

```js
export default {
  data() {
    return {
      arr: [1, 2, 3]
    };
  },
  computed: {
    twiceArr() {
      return this.arr.map(x => x * 2);
    } 
  }
}
```

While writing the `twiceArr` computed property, the lack of type inference means that the IDE is unable to bring up suggestions for array methods when you are typing `this.arr`. Moreover, say a few weeks from now, and somebody decides to change the data `arr` from an array to an object like `{}`. This means that `this.arr.map()` will throw a runtime error (since objects do not have the `map` method). Ideally, the IDE should warn about this illegal statement, *except that it cannot*, because it is unable to infer the type of the data `arr`.

Of course, this may sound more like a minor nuisance than an actual problem. However, when your app grows big (which it will!), and when different developers come into the same project, it will really stymie development speed and add on to the confusion.

### Really Weird Bugs

This I am sure many Vue developers have experienced before. Knowing the difference between a normal function `function() {}` and an arrow function `() => {}` and how Vue binds the `this` keyword differently in them is *not* something I would exactly call beginner friendly. Stackoverflow for instance has more than a few questions asking for this exact same problem ([1](https://stackoverflow.com/questions/42971081/use-arrow-function-in-vue-computed-does-not-work), [2](https://stackoverflow.com/questions/44915753/es6-arrow-function-this-puzzle-in-vue-js-official-github-example), [3](https://stackoverflow.com/questions/58951720/how-can-i-implement-arrow-function-in-vuejs) to name a few).

For example:

```js
data: () => ({ // arrow function =(
  user: "Timmy",
  userCopy: this.user // undefined!
}),
```

I remember in my first few months of learning Vue, I made the mistake of writing my `data` with an arrow function like the above, and pulling my hair out, because I cannot figure out why `userCopy` was returning `undefined`!

Yes, to somebody more experienced, these *are not weird bugs and are well documented features* when you actually learn about how Vue works under the hood. However, you do not really expect a beginner to learn how the framework works when he is just starting out.

### Difficult to Collaborate

Which leads me to my last point: collaboration is rather cumbersome. Type inference, type checking, and static code analysis are one of those few things that you only notice when you suddenly have to deal with their absence. If you are not yet a TypeScript convert (or have otherwise not used a statically typed language before), this point might sound foreign to you.

Even so, I believe that anybody who has worked with a non-trivial project with a significantly large codebase (upwards of 10K LOCs) would experience the pain of working with one. Do you often find yourself taking much longer than usual trying to understand and trace the SFC code not authored by you (or which you have written a while ago)? Jumping within the `data` to the `methods` section, to the lifecycle hooks and to the actual template before forgetting what the relevant function defined in `methods` did?

OK, I did mention that I was not going to talk about code organisation. But the point remains: with better type inference and static analysis, it would make collaboration and understanding the code much easier, especially when you have confidence in the types that you are using and/or returning.

## Benefits of Composition API

If you did not know already, **Vue 3 itself was rewritten with TypeScript**. Watch [this great talk](https://www.youtube.com/watch?v=WLpLYhnGqPA) by Evan You about the design considerations with Vue 3, and why the team have decided to go with TypeScript.

The short summary is: Vue 3, together with the Composition API, solves all of the pain points mentioned earlier, and helps make your developement experience much better. For example. in the `setup` of the Composition API, the improved type inference means that you get much better IntelliSense within VSC, and have actually useful suggestions which pertain to the `string` type:

![Composition API IDE Screenshot](https://dev-to-uploads.s3.amazonaws.com/i/7q5shmokvgh780jnkquk.png)

> Look, arrow functions too! The blasphemy!

Note that you **do not have to be using TypeScript** in your Vue 3 projects to benefit from any of this. And if you do want to try out TypeScript, simply change the script tag to `<script lang="ts">` so that your IDE knows to lint the code as TypeScript. And voila! It is that simple. Unlike Vue 2,  there is no need to learn another [Class Based API](https://vuejs.org/v2/guide/typescript.html#Class-Style-Vue-Components) just to get [marginally better TypeScript support](https://composition-api.vuejs.org/#type-issues-with-class-api). This native TypeScript support is the one change that I am most excited about in Vue 3.

## Conclusion

The question remains: is learning or using the Composition API worth it? Even though the Options API [will not be deprecated in Vue 3](https://composition-api.vuejs.org/#adoption-strategy) and can be used together within the same codebase?

Whether to *learn* it or not is an easy question to answer: learn it. Learning is after all, inevitable, especially in the field of web development where a new tool comes out once every few months.

The question of whether to *use* it in a production site is a little more complex. Personally, I would, from the moment Vue 3 is production ready, only write new features using the Composition API. Refactoring the "old" Options API code on the other hand, is a decision only you can make. If the feature is continuously being worked on, I would say it makes sense to refactor to the Composition API to take advantage of all the benefits mentioned earlier.

But why take it from me? As of this article, [Vite](https://github.com/vitejs/vite) has just released its first beta version, and apps bootstrapped with it comes with Vue 3 and all its glory out of the box (plus, the hot module reloading is amazingly fast). Try it out for yourself and let me know what you think!