Currently it's in the beta release, and if you want to get hands-on with the latest changes you can try to install it and followup the changes in their github release. As a VueJS developer, I have experienced the current code implementation of Vue 2, and when I tried the Vue 3, I noticed there are some breaking changes.
But don't get me wrong, I personally like the breaking changes as I believe it will help to improve the code quality and lesser chance of unexpected bugs.
Also, these breaking changes are coming from the agreed RFC by the Vue Core team, so check them out for more detail. Alas, here we go! In the Vue 2, usually the plugin installation will be done in the global instance of the Vue object, and then we create a new instance of the Vue to initialize the Vue app.
This implementation has a flaw if you need to create multiple Vue app in the same page.
Since it uses the global Vue instance to install the app, you can't initiate multiple Vue app with different plugins to be installed.
This can lead to the pollution of the Vue instance. In the Vue 3, plugin installation and app initialization are immutable from the original Vue instance, since you must initiate the Vue app first before installing the plugins.
Notice that there's no global Vue defined and mutated here.
With this, now you can be sure that every plugin used on each application is specific and won't pollute other Vue app. More details and the reason behind in the RFC: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0009-global-api-change.md.
💓 Before I make anyone panic here, please note that this changes on v-model API is not affecting the usage of v-model in the native elements like ,
The model option that I referred on the title above is the model option that we use for custom v-model on the custom component.
So yes, this breaking change is only meant for the custom component that uses model option, as mentioned here that it will be removed in the Vue 3.
In the Vue 2, you can only define one v-model to have a two-way data binding. If you need multiple props to have two-way data binding, you can use .sync instead. Having v-model and .sync directive takes more learning curve while they are doing similar things.
Thus, in Vue 3 the .sync are deprecated, and then you can use multiple v-model instead! More consistent, so less bikeshedding with your teammates, profit!
More details and the reason behind in the RFC: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0011-v-model-api-change.md.
Do you love the concept of Event Bus in Vue? If yes, then this might disappoint you a bit.
Vue has no official documentation for Event Bus, but the API built in the Vue 2 instance allows us to create a publish-subscribe object with the vm.$emit and vm.$on method.
There is a good motivation behind this changes, because Vue encourages more state-driven data flow, which data are passed from parent components to its child, and events are emitted from the child to the parent component.
But of course using Event Bus pattern is still allowed in the Vue 3.
If you still need it, you can install any 3rd party library or write your own. More details and the reason behind in the RFC: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0020-events-api-change.md.
Filter is one of the early feature introduced by Vue to easily map your rendered value. It is usually used for price tag, currency, and capitalize.
The usage of filter is usually to beautify your vue template code:.
Filter are encouraged for simplicity and re-usability.
But, it is also replaceable with methods because there is no difference in terms of performance.
Removing filter will encourage more explicit methods to be defined on each component, and if you need to reuse the filter function on multiple components, it can just be simply imported and registered as part of the method.
This is just my personal opinion, but if you're looking forward for the Vue 3 Composition API, you might notice that filter can also be easily replaced as well by manually return the filter function in the setup.
Deprecating filter will help us to code more consistently and no more bikeshedding on deciding whether the function shall be registered in the filter or method.
More details and the reason behind in the RFC: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0015-remove-filters.md. With the upcoming release of Vue 3, the changes are going to a better direction for the sake of the code quality. All of these breaking changes are considered carefully in the RFC, so feel free to check and contribute to the discussion!
Lastly, thank you for going through this article!
I hope this help anyone that consider to migrate their existing Vue 2 application to the Vue 3, to be aware of the changes and be prepared!
What do you think of the breaking changes? Your comment and suggestion to help me improve this documentation and my writing skill is very much appreciated!