In this video, let's take a quick look at what the Composition API is. Okay, so the Composition API, sometimes referred to as CAPI for short, is an alternative way of defining component internals, such as data, methods, and computed prompts. It does not necessarily replace the Options API. The Options API is the way that you wrote your components in Vue 2.
Canpy, therefore, is an addition to the framework that can be used as an alternative or even alongside the Options API. js. In fact, in 2019, at the time that the RFC for the Composition API was released, it was actually called the Functions API. So, some of the functions that are exposed include Watch, Ref, Reactive, Computed, and a whole lot more.
Essentially, CAPI is an umbrella term that covers the Reactivity API, the Lifecycle Hook API, and the API for dependency injection. In other words, provide and inject. js library. If you're wanting to use the Composition API on a Vue 2 project, you can use the Vue 2 Composition API plugin, and everything else we cover will work mostly the same.
7, the Composition API is built-in, but any lower version of Vue 2, you have to use the plugin. All right, now that we know what it is and what version of you we need to use it, the big question is, so what? If you're anything like me, when you first heard about the Composition API, your first thought was, yeah, that kind of looks neat and all, but how does this actually help me in my real day-to-day job? Well, to answer that question, let's first take a look at some of the problems that you might encounter while using the Options API.
The first problem with the Options API is that as our components grow in functionality, the logical concerns of our component tend to be segmented across different component options. Let's take a look at a table component as an example. Imagine we have a table component that is meant to handle loading data from an external source. It should be able to sort, filter, and also paginate that data.
Each of those tasks is a different logical concern. In the image that you see here, you can get a feel for how each logical concern designated by a different color is scattered throughout the different options. That's because each concern needs to keep track of the data, have methods defined, and so on. Well, with the Options API, we must break up those logical concerns in order to fit things into the different options based on the functionality that they provide.
Thus, when making large components with the Options API, you often find yourself jumping around the file just to handle a single concern. Some of you might be thinking, well, my components never get that long. And for many components that are properly focused, this won't be an issue. However, there are some cases where components are just more complex by necessity.
And unfortunately, this can end up happening before you know it. Now compare that same table component written with the composition API. Notice how all the logical concerns are grouped together now. This makes the code easier to read and reason about, especially when working in a team environment where you might not have been the one to code the component from the beginning.
To summarize, the first benefit of the Composition API is that it enables us to group together logical concerns for better code legibility and understanding. Now, let's take a look at the next problem with the Options API. Mixins are the primary mechanism for reusing logic between components in Vue 2. However, they do come with a few less than desirable side effects.
Number one, they obscure the source of component data, methods, and so on. So let's say you defined a loading data property in a mixin. When you put the mixin to use in a component, just looking at the component, you'd have no idea where this dot loading is coming from. That is, without digging into each one of the component mixins, and then in a real application, there could be more than just the one mixin.
Furthermore, if it was a global mixin, you'd better hope the name of the data property itself is revealing enough, or you're familiar with the plugin or library that injected it. Otherwise, there's really no way to backtrack it to its source. Now, not only do mixins obscure the source of shared component data, properties, methods, and so on from the developer, but they can also shield them from your IDE, as it's not being mixed in via a transparent, normal JavaScript mechanism. That means features like autocomplete and IntelliSense just won't work as well as they could.
Secondly, mixins can easily lead to naming collisions. For instance, you might have a brand mixin and a product mixin that both set a data property called name. Then attempting to use both of the mixins at once would cause the name data property to be lost on whichever mixin is used first. While both of these issues can be alleviated by prefixing mixin data properties, methods, and so on with the name of the mixin, there is nothing in the code itself that really ensures individual developers actually do this.
Besides that, the prefix properties just feel more clumsy to work with and are certainly longer to type. Now, compare this with sharing component logic with the Composition API. In the Composition API, we can replace mixins with composables. The term composable is commonly used when using the Composition API to extract component logic.
As you can see here, each composable can use the same data names and so on without the fear of clashing with any other composable. That's because once you use the composable inside of a component, you have complete control to rename things as the context demands. You probably also notice that this approach allows us to easily see where each data property is coming from. The name is a variable defined on the left-hand side of an equals operator.
and its source is the function called on the right hand side. So there's no need to go digging through mixins in order to find where something is coming from. So to summarize, the second benefit of the Composition API is that it allows us to more intuitively and predictably extract component logic from the template in order to share it across multiple components. And in my opinion, this is really the greatest strength of the Composition API.
and is truly going to allow for some game-changing practices moving forward. Finally, the last issue with Vue 2 was that while it did support development with TypeScript, the support was limited at best and painful at worst. However, this all changes with the Composition API. With the Composition API, the initial value of refs can be used to infer their types, as can the value of computed properties be inferred from their return.
Interfaces can be used when defining reactive data. And a number of other enhancements made just for TypeScript are now possible. All right, now that we know why it's worth using the Composition API, let's learn how all this works and how you can use it in your own applications.