If you're keeping up with the Vue ecosystem, you'll likely know that Vue 3 is currently in pre-alpha, and coming with it is the new Composition API. This is a new optional syntax for writing "composition functions" -- functions that can easily be reused between components.
Vue 2 supports a few ways to reuse code between components;
- Renderless components
- Higher-order components
These methods of reuse each come with their own drawbacks, namely:
- Unclear where component options are coming from (mixins)
- Namespace clashes (higher-order components, mixins)
- Performance costs (higher-order components, renderless components)
The Composition API aims to solve these issues by offering a mechanism for logic reuse that doesn't encounter these issues. Re-usable code can be extracted into "composition functions", which any component can then use within the new
setup component option.
Unclear component options are no longer an issue because any properties exposed to the template are now returned from an explicit call to a composition function
Namespace clashes are no longer an issue because you can assign any name you like to both the composition functions and their return values
Performance costs are reduced because no unnecessary component instances are created for logic reuse
If we take a look at the issues with the current API that we listed above, we'll notice that these are only prominent in larger projects, which make heavy use of the code reuse patterns. In small to medium size projects, these issues are often not a problem.
The Composition API was built with these large-scale projects in mind, where components get extremely large and contain multiple features that become difficult to reason about.
So do you need to use the Composition API for smaller projects? Probably not. That being said, I do believe that there are some benefits to using it in small to medium size projects, those being readability and type-checking.
The Composition API improves the readability of Vue code by making it obvious where the properties exposed on the template come from. If you want to know where a property comes from you can trace it back to the composition function that declared it in the
setup method. You can then scope your focus to the contents of that composition function, making it much easier to reason about what you are reading.
Personally I am quite a big fan of the Composition API, hence why I am writing about it. I think however that you should not immediately rewrite your app using the new API. If and when you do start to migrate your app, you should definitely take advantage of the fact that the new API is purely additive and is able to be used seamlessly with the current API to slowly migrate parts of your app that suffer from the re-usability issues that the Composition API aims to solve.
What are your thoughts?