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 to this particular DEV post 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:
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, 2, 3 to name a few).
For example:
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 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:
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 just to get marginally better TypeScript support. 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 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 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!
Top comments (1)
I'm not sure Vue next is ready for production or not.
At the time of writing, Vue next still have a more than 102 open issues and 88 PRs in github -- which wasn't include few more bugs that we found in migration process.