New Composition API
One of the first things that stood out to me is the addition of the entirely new Composition API, which will not be outright replacing the Options API that Vue 2.x components utilized but will presumably become the de facto design pattern for future Vue applications. To quote the development team’s reasoning behind this decision:
“Organizing logics with component’s options (data, computed, methods, watch) works in most cases. However, when our components get bigger, the list of logical concerns also grows. This can lead to components that are hard to read and understand, especially for people who didn't write them in the first place.”
At Highland, we’ve found this to be incredibly true of some of our larger frontend development projects — perhaps even some that were never intended or expected to be so large. In any case, legibility/maintainability/comprehensibility — basically a lot of ‘bilities — became increasingly difficult and abstract. The new Composition API should help quite a bit with that, as it creates a code flow that allows us to collate logical concerns in a more structured way — without jumping around between different option groupings within the component where the logic can bleed together. In a sense, this is just another step forward from monolithic JS application libraries and ecosystems that were impossible to maintain. With code compiling and so forth, it only makes sense to continue to create as much code structure as possible within the framework.
The essential difference between these two APIs is the Composition API defines its data structure and assigns lifecycle hooks, watchers, and so forth from one method, the (setup) method. The result is much cleaner code, that’s a lot easier to refactor later (you won’t find yourself creating a never-ending chain of methods as your feature set evolves). The new References concept is going to make understanding reactivity a lot easier in my opinion as well. Creating something as a Reactive Reference within your component assures that it is reactive throughout — no more worrying about what isn’t reactive, or using tricks like Vue.set to make properties that weren’t in the original component design reactive. This is great for helping support the development process with the Vue.js app.
Teleport (new to Vue.JS 3.0)
Teleport is a brand new feature of Vue 3.0 JS framework that effectively replaces the need for 3rd party libraries such as Vue Portal. Probably the most common use case for Teleport and this type of feature, in general, is the positioning of elements on the page. For example, if you have some HTML nested deep within your Vue component tree for a modal window, the positioning of the modal would be relative to the parent component. In that case, we want the modal to be living at a pretty high level within the DOM so that it’s positioning can easily be derived relative to the body container. With teleport, it’s really as easy as wrapping the desired bit of HTML in a
<teleport> tag with a
to attribute giving it a selector to append to. For example (taken from Vue 3.0 docs):
In the given example above, the modal is appended to the body tag instead of residing within the nested component HTML. It’s the same thing as Vue Portal, but unlike Vue Portal, you don’t have to predefine a destination for your HTML, therefore with less dependencies any selector in theory should work as a target in Teleport.
In conclusion, Vue 3.0 clearly attempts to solve some of the common web development problems of Vue 2.0, and also offers some new built-in functionality that wasn’t present in the last release. For those offering Vue.js development services covering single page applications and web apps to user interfaces, Vue 3.0 offers a lot. All in all this release looks promising for Vue.js developers, without breaking too many things. Happy coding!
To find out more about Highland and how they can be a Vue.Js development company or web development company for your business requirements, contact us today.
Other Vue.JS blogs: