With the release of the VueJS 3 "Request for Comment" documentation about two weeks ago, Evan You introduced the VueJS function-based API and has set the VueJS community ablaze. These new ideas are still in the "Request for Comments" stage, so they're far from set in stone, but because the RFC introduces such significant changes, I made a quick summary of what you need to know.
NB: All this information and much more is in the RFC, so I do suggest you read that.
Setup
VueJS 3 departs from the option-based API we've grown to love and introduces the setup() function, which will be where all the magic happens. This function single-handedly sets up the the logic for our component and returns data that's exposed to the template. The option-based API will continue to work even in VueJS 3, but this new function-based API will be the new standard.
For all the functionality we're used to from VueJS like reactive data, computed values, methods and watchers, we import functions from vue and use them in our setup() function. Here's a basic example from the RFC:
<template>
<div>
<span>count is {{ count }}</span>
<span>plusOne is {{ plusOne }}</span>
<button @click="increment">count++</button>
</div>
</template>
<script>
import { value, computed, watch, onMounted } from 'vue'
export default {
setup() {
// reactive state
const count = value(0)
// computed state
const plusOne = computed(() => count.value + 1)
// method
const increment = () => { count.value++ }
// watch
watch(() => count.value * 2, val => {
console.log(`count * 2 is ${val}`)
})
// lifecycle
onMounted(() => {
console.log(`mounted`)
})
// expose bindings on render context
return {
count,
plusOne,
increment
}
}
}
</script>
But why?
If that example doesn't make it clear why this change was introduced, or if it feels like a step back in terms of usability, I understand. I had the same initial reaction and it took me a bit of time to figure out why this change was necessary. The v2.x API is widely loved and is often the reason why people move to VueJS from other frameworks like ReactJS or AngularJS, so a change this drastic seems like a strange idea.
Encapsulation is king
The component API was created in part to make it easier to reuse code across your application. While VueJS is seriously modular and uses components, the current option-based API doesn't allow for an easy extraction of functionality that relates to a single piece of functionality or data. You need to define your data(/state), computed values and methods separately, while they might all be related. This gets confusing when components grow and methods deal with different pieces of data.
This is where the new function-based API comes in. It allows you to extract all code related to a piece of logic and put it together in what they call a "composition function", which returns reactive state. An example given in the RFC uses one of those composition functions to extract the logic of listening to the mouse position:
function useMouse() {
const x = value(0)
const y = value(0)
const update = e => {
x.value = e.pageX
y.value = e.pageY
}
onMounted(() => {
window.addEventListener('mousemove', update)
})
onUnmounted(() => {
window.removeEventListener('mousemove', update)
})
return { x, y }
}
// in consuming component
const Component = {
setup() {
const { x, y } = useMouse()
return { x, y }
},
template: `<div>{{ x }} {{ y }}</div>`
}
If we compare this to how we would write this functionality in the v2.x API, we can see that the functionality related to using the mouse position is all over the place, where in the v3.x API, it's quite nicely grouped in a singular function:
<template>
<div>
{{ x }} {{ y }}
</div>
</template>
<script>
export default {
data() {
return {
x: 0,
y: 0,
};
},
mounted() {
window.addEventListener('mousemove', this.update);
},
beforeDestroy() {
window.removeEventListener('mousemove', this.update);
},
methods: {
update(e) {
this.x = e.pageX;
this.y = e.pageY;
},
},
};
</script>
And more
Encapsulation isn't the only reason why these changes are useful, so here are two other reasons why this change might be what VueJS needs.
The current option-based API in VueJS has an issue in that it doesn't properly support TypeScript type inference. The proposed changes fix this issue, and achieve full typing support, with TS code looking almost the same as JS code as a cherry on top of an already very useful pie.
VueJS is loved for its extremely small bundle size and this change shrinks that bundle even more. Since function and variable names can be shortened with standard minification (while object/class methods and properties can't), the code simply compresses better.
Thoughts?
Initial reactions to the RFC have been mixed, with some users comparing these changes to React and suggesting VueJS is losing its edge. My first response was far from positive too, but the longer I look at it, the more the encapsulation advantage starts to outweigh the cleanliness of the current API.
What are your thoughts?
Latest comments (75)
Totally agree. I learned JS frameworks using Vue.js but it's disenchanting seeing nearly every tool or library around not supporting the current stable version v2 and instead only posting docs supporting things like Vite + v3 Beta etc...
Just makes the ecosystem a mess where I'm constantly having to compare versions and dip back into archives for what is currently Vue Stable.
Add to that, that you gave a Vue CLI (and UI and the inherent confusion there) that don't discriminate against plugins that aren't supported in the very tool that you're using to search for plugins. Just seems like insanity to me.
Having started 3 years ago with Vue, it seems that the Vue ecosystem really needs to be reigned in.
Hey please help me
How can I integrate ccavenue with Vuejs and Laravel
It seems that the new Vue can be really useful for small startups as it allows them to develop an MVP as fast as possible. It's a quick and easy yet powerful tool to build a working prototype, as well as to add originality to a bigger project. I've found a captivating piece dedicated to VueJS 3 features and modifications and how your project can benefit from them.
I feel like I wasted a couple of my years. I should have chosen React. At least that would have given me a milage in the job market. I chose Vue just because of the love of it. We're not engaging in Vue projects. One debacle with Angular is enough already :(
NOOOOOO. Are you freaking kidding me? This is terrible. I don't care if it shaves .2 milliseconds off load time. This just sucks. C'mon Evan seriously? The reason vue was great is because it wasn't trying to be reacts bff.
This should NOT be a new version, this should be a split off entirely. Because you know what will happen....this will eventually fall into the old unsupported version.
Its already happening on the mobile side. Vue native is nothing more than react native with some syntax changes at this point. Why are you heading that way? Vue is fantastic like it is, just leave it alone. This might be one of the biggest blunders in all of software development. So disgusted by this.
why are developers too clumsy, evan yu has not even released vue js 3 yet
To be honest, both of these look horrible. I am so used to doing
@Component() export class MyApp extends Vue { blar blar }
Call me crazy, but to me the logic of mouse position listening seems much more easier to follow with the Option API. Like if you do too.
The Vue Core team has listened to the community feedback and decided to keep the current API and provide the new API as a plugin as stated in this tweet by Guillaume Chau twitter.com/Akryum/status/11431148....
Great decision making, it takes courage to change course!
Add it as a plugin, see if the community likes it, fixes the problems and then maybe merge it in the mainline.
Firstly this is purely an addative API - you don't need to use it, nor will you be forced to use it. The beauty about Vue is you can use the strong API given to you as default per 2.6.x or you can opt in to use the 3.x API.
Their need to intro this to fix mixins due to name clashes (i.e solve it using hooks principle) - doesn't make too much sense to me but hey Evan's, made some pretty good decisions so far.
You can always resolve to custom naming convensions with your mixins to derive source and prevent clashes
Vue is starting to look a bit like React :/ Not bad thing tho
Vue.js maintainers, for the sake of your project talk to Python core devs about python3 and learn from their mistakes. It looks like you are going down the same path and it's not a pleasant one...
that's exactly when i jumped track
My view maybe a bit simplistic, but I think I have a few points to make. While I've been seriously looking a Svelte 3.0 (compiler, not a framework that's similar in Vue2.0 syntax), I still love the current Vue from top to bottom. However, new complexity "just because" is not what I wanted from Vue - simplicity is. It's not the fact that I will be able to continue to use Vue as I use it now in 3.0. It's really the fact that "NOT EVERYONE USING VUE WILL BE ON THE SAME PAGE" - this can cause fragmentation in the development community, on dev teams and confuse, or even turn off, new Vue adopters seeking to learn the framework. Add the RFC as an optional plug-in, not a core change. Kind of like how we can write JSX within Vue. I'm not looking to defend my remarks - just wanting to state my opinion...period...
I don't think the issue here is solely the RFC, it's the way the Vue team communicates these changes to the community and responds to criticism from people. The way I have seen the Vue team interact with the community and criticism, it's not a good look in my opinion.
Just look at that RFC, people are worried and confused, and I don't think Evan is doing a very good job quelling the fire, to be honest.
One of the biggest reasons people either choose Vue over React or move to it from React was the fact it's cognitively a lot simpler. React gets messy and complex once you start building large apps with it.
All people see with this new RFC is the Vue team making more work for developers and introducing code changes that make Vue look more like React.
Coupled with the fact Evan has been showing a demo of v3 (a secretive prototype not publicly available) and some impressive benchmark numbers, but it seems to me that Vue 3 is nowhere near done and won't be done in 2019.
There seems to be a lot of uncertainty, and the perception to me is they're stuck between a rock and a hard place. They don't know how Vue 3 will look, they want to improve it, but at the same time, they're being held back by their own success (see Angular 1.x).
It raises the question many others are asking: why Vue 3 instead of React?
Maybe the best comment yet. EXACTLY
We should all just go Vanilla. At least I'm trying. Did a lot with React, Angular, Vue, now digin Svelte but I'm tired od learning.
Bein' selfemployed gives me the posibility to choose the stack and that is awesome.
My view maybe a bit simplistic, but I think I have a few points to make. While I've been seriously looking a Svelte 3.0 (compiler, not a framework that's similar in Vue2.0 syntax), I still love the current Vue from top to bottom. However, new complexity "just because" is not what I wanted from Vue - simplicity is. It's not the fact that I will be able to continue to use Vue as I use it now in 3.0. It's really the fact that "NOT EVERYONE USING VUE WILL BE ON THE SAME PAGE" - this can cause fragmentation in the development community, on dev teams and confuse, or even turn off, new Vue adopters seeking to learn the framework. Add the RFC as an optional plug-in, not a core change. Kind of like how we can write JSX within Vue. I'm not looking to defend my remarks - just wanting to state my opinion...period...
What do you think about svelte?
This reminds me that sometimes I feel tired that over the years I've been learning so many technologies to do the same exact thing :D
Some comments may only be visible to logged-in visitors. Sign in to view all comments.