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.
