VUE TIPS

COLLECTION
Michael Thiessen

Second Edition
 Vue Tips Collection
1. Forgotten Features
1. Private properties with script setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. h and Render Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Directives in Render Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
4. Custom Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
5. Deep Linking with Vue Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Destructuring in a v-for . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Global Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Next Tick: Waiting for the DOM to Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. A simpler way to pass lots of props . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Restrict a prop to a list of types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. toRef default value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Special CSS pseudo-selectors in Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. How to watch anything in your component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Watching Nested Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Watching Arrays and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Vue to Web Component in 3 Easy Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Slots and Reusability

17. 6 Levels of Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
18. Nesting slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
19. Recursive slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
20. Conditionally Rendering Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
21. Using default and named slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
22. Default Content with Nested Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
23. Default Content with Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
24. The limitations of props . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
25. Shorthand for named slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
26. Slot Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
27. Reusable Components Aren’t What You Think . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
28. Splitting Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
29. Improve reusability by converting template props into slots . . . . . . . . . . . . . . . . . . 47
30. Understanding scoped slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

ii   
Logic Lore
31. A bunch of composable mini tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
32. Configuring Composables with the Options Object . . . . . . . . . . . . . . . . . . . . . . . . 53
33. Example of a Composable Using the Options Object Pattern . . . . . . . . . . . . . . . . . . 56
34. The Right Number of Options for Composables . . . . . . . . . . . . . . . . . . . . . . . . . . 59
35. Async Without Await . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
36. Dynamic Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
37. Flexible Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
38. Ref vs. Reactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
39. Too Many Props/Options is a Smell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
40. Nesting Reactive Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
41. When ref and reactive work the same . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
42. Reassigning and Reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
43. Template Refs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
44. Avoid Ref Soup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
45. Composable Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
46. Global Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
47. Inline Composables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
48. From Options to Composition — The Easy Way . . . . . . . . . . . . . . . . . . . . . . . . . . 89
49. Shallow Refs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
50. Structuring Composables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
51. How to Watch Props for Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
52. Wrapping Non-Reactive Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
53. Writable Computed Refs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Nuxt Nuggets
54. Flatten Nuxt Content Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
55. Auto-imports in Nuxt 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
56. Nuxt Content Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
57. Handle Client-side Errors in Nuxt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
58. Prose Components in Nuxt 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
59. Reactive Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
60. SSR Safe Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
61. Nuxt’s Powerful Built-In Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
62. Using useHead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
63. Using useRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

VUE TIPS COLLECTION    iii

 Powerful Patterns
64. The Hidden Component Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
65. When to use the Hidden Component Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
66. Async Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
67. Component Variations with the Base Component Pattern . . . . . . . . . . . . . . . . . . . .123
68. Calling a Method from Outside of the Component . . . . . . . . . . . . . . . . . . . . . . . . 125
69. Component Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
70. Compound Components (Quickly) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
71. Reusability Fundamentals: The Configuration Pattern . . . . . . . . . . . . . . . . . . . . . . 133
72. Creating Magic with Context-Aware Components . . . . . . . . . . . . . . . . . . . . . . . . 135
73. Controlled Props — or How to Override Internal State . . . . . . . . . . . . . . . . . . . . . . 137
74. Decouple Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
75. Directly accessing parent components (and why) . . . . . . . . . . . . . . . . . . . . . . . . 140
76. Default Content and Extension Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
77. Extract Conditional Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
78. Lonely children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
79. Make Testing Easy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
80. Master computed refs (and computed props) . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
81. Optimize for Humans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
82. How to make a variable created outside of Vue reactive . . . . . . . . . . . . . . . . . . . . .152
83. Reusing Code and Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
84. Where do you put shared state? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
85. Smooth dragging (and other mouse movements) . . . . . . . . . . . . . . . . . . . . . . . . 156

Template Tidbits
86. How to get rid of extra template tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
87. Another Use for the Template Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
88. Debugging Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
89. Detect mouse hover in your component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
90. Dynamic Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
91. Dynamic Slot Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
92. Looping Over a Range in Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
93. Multiple v-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
94. Nested Ref Properties in Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
95. Reactive SVG components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
96. Static and dynamic classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
97. Teleportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
98. Computed Props in Your Template: v-memo . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
99. v-once . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
100. When should you use v-if? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

iv   
All the Others
101. Aria roles you didn’t know you needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
102. A better way to handle errors (and warnings) . . . . . . . . . . . . . . . . . . . . . . . . . . 182
103. Components are Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
104. Destructuring and Reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
105. Get rid of the double curly braces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
106. Force Vue to Re-Render Correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
107. Forcing a Component to Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
108. Hybrid API: Composition API + Options API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
109. What are all these loops for? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
110. Lightweight State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
111. Multi-file single-file components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
112. Performance Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
113. Refresh a Page in Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
114. Stacking contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
115. Start with the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
116. Using two script blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
117. UI states to get right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
118. Check Vue’s Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

VUE TIPS COLLECTION    v

1 Forgotten
Features
All those things you forgot Vue could do, or didn't
know about in the first place
1.
Private properties with script setup

You can limit what properties are available when a component is accessed by $ref :

export default {
expose: ['makeItPublic'],

data() {
return {
privateData: 'Keep me a secret!',
};
},

computed: {
makeItPublic() {
return this.privateData.toUpperCase();
},
},
};

With only makeItPublic exposed, you can't access the privateData property through a
$ref anymore:

this.$refs.component.privateData // Will always be undefined

If you’re using <script setup> , everything is locked down by default. If you want to expose
a value you have to do so explicitly:

VUE TIPS COLLECTION    2

 <script setup>
import { ref, computed } from 'vue';
const privateData = ref('Keep me a secret!');
const makeItPublic = computed(
() => privateData.value.toUpperCase()
);

// We don't need to import this because it's a compiler macro

defineExpose({
makeItPublic
});
</script>

Here defineExpose is a compiler macro, not an actual function, so we don't have to import
anything.

You can find more info on this on the official docs.

3   FORGOTTEN FEATURES
2.
h and Render Functions

When using the render function instead of templates, you'll be using the h function a lot:

<script setup>
import { h } from 'vue';
const render = () => h('div', {}, 'Hello Wurld');
</script>

With the Options API the render function works exactly the same, we just have to define it
slightly differently:

<script>
import { h } from 'vue';
export default {
render() {
return h('div', {}, 'Hello Wurld');
}
}
</script>

It creates a VNode (virtual node), an object that Vue uses internally to track updates and what
it should be rendering.

The first argument is either an HTML element name or a component (which can be async if
you want):

<script setup>
import { h } from 'vue';
import MyComponent from './MyComponent.vue';

const render = () => h(MyComponent, {}, []);

</script>

VUE TIPS COLLECTION    4

 The second argument is a list of props, attributes, and event handlers:

<script setup>
import { h } from 'vue';
import MyComponent from './MyComponent.vue';

const render = () => h(MyComponent, {

class: 'text-blue-400',
title: 'This component is the greatest',
onClick() {
console.log('Clicked!');
},
}, []);
</script>

The third argument is either a string for a text node, an array of children VNodes, or an object
for defining slots:

<script setup>
import { h } from 'vue';
import MyComponent from './MyComponent.vue';

const render = () => h(MyComponent, {}, [

'Simple text node',
h('span', {}, 'Text inside of a <span> element'),
]);
</script>

These render functions are essentially what is happening "under the hood" when Vue compiles
your single file components to be run in the browser.

But by writing out the render function yourself, you are no longer constrained by what can be
done in a template. You have the full power of Javascript at your fingertips ✋
This is just scratching the surface on what render functions and h can do. Read more about
them online.

5   FORGOTTEN FEATURES
3.
Directives in Render Functions

Vue comes with some methods to help you use custom directives on your VNodes:

<script setup>
import { resolveDirective, withDirectives, h } from 'vue';

// Find the already registered directive by name

const focusDirective = resolveDirective('focus');

// Wrap the button with the directive

const render = () => withDirectives(
h('button', {}, []),
// An array of directives to apply
[
[focusDirective]
]
);
</script>

Render functions are defined slightly differently when using the Options API:

import { resolveDirective, withDirectives, h } from 'vue';

export default {
render() {
// Find the already registered directive by name
const focusDirective = resolveDirective('focus');

VUE TIPS COLLECTION    6

 // Wrap the button with the directive
return withDirectives(
h('button', {}, []),

// An array of directives to apply

[
[focusDirective]
]
);
}
}

You can find more info on using withDirectives on the docs.

7   FORGOTTEN FEATURES
4.
Custom Directives

In script setup you can define a custom directive just by giving it a camelCase name that
starts with v :

<script setup>
const vRedBackground = {
mounted: (el) => el.style.background = 'red',
}
</script>

<template>
<input v-red-background />
</template>

With the Options API:

export default {
setup() {
// ...
},
directives: {
redBackground: {
mounted: (el) => el.style.background = 'red',
},
},
}

VUE TIPS COLLECTION    8

 Registering a directive globally:

const app = createApp({})

// make v-focus usable in all components

app.directive('redBackground', {
mounted: (el) => el.style.background = 'red',
})

And since a very common use case is to have the same logic for the mounted and updated
hooks, we can supply a function instead of an object that will be run for both of them:

<script setup>
const vRedBackground = (el) => el.style.background = 'red';
</script>

<template>
<input v-red-background />
</template>

You can find more info on custom directives in the docs.

9   FORGOTTEN FEATURES
5.
Deep Linking with Vue Router

You can store (a bit of) state in the URL, allowing you to jump right into a specific state on the
page.

For example, you can load a page with a date range filter already selected:

someurl.com/edit?date-range=last-week

This is great for the parts of your app where users may share lots of links, for a server-rendered
app, or for communicating more information between two separate apps than a regular link
provides typically.

You can store filters, search values, whether a modal is open or closed, or where in a list we've
scrolled to — perfect for infinite pagination.

Grabbing the query using vue-router works like this (this will work on most Vue frame-
works like Nuxt and Vuepress too):

// Composition API
const dateRange = useRoute().query.dateRange;

// Options API
const dateRange = this.$route.query.dateRange;

To change it we use the RouterLink component and update the query :

<RouterLink :to="{
query: {
dateRange: newDateRange
}
}">

VUE TIPS COLLECTION    10

 6.
Destructuring in a v-for

Did you know that you can destructure in a v-for ?

<li
v-for="{ name, id } in users"
:key="id"
>
{{ name }}
</li>

It’s more widely known that you can grab the index out of the v-for by using a tuple like this:

<li v-for="(movie, index) in [

'Lion King',
'Frozen',
'The Princess Bride'
]">
{{ index + 1 }} - {{ movie }}
</li>

When using an object you can also grab the key:

<li v-for="(value, key) in {

name: 'Lion King',
released: 2019,
director: 'Jon Favreau',
}">
{{ key }}: {{ value }}
</li>

11   FORGOTTEN FEATURES
It's also possible to combine these two methods, grabbing the key as well as the index of the
property:

<li v-for="(value, key, index) in {

name: 'Lion King',
released: 2019,
director: 'Jon Favreau',
}">
#{{ index + 1 }}. {{ key }}: {{ value }}
</li>

VUE TIPS COLLECTION    12

 7.
Global Components

When you register a component globally, you can use it in any template without importing it a
second time:

// Vue 3
import { createApp } from 'vue';
import GlobalComponent from './GlobalComponent.vue';

const app = createApp({})

app.component('GlobalComponent', GlobalComponent);

In Vue 2 you can register global components like this:

// Vue 2
import Vue from 'vue';
import GlobalComponent from './GlobalComponent.vue';
Vue.component('GlobalComponent', GlobalComponent);

Now you can use GlobalComponent in your templates without any extra work!

Of course, globally registered components have the same pros and cons as global variables. So
use this sparingly.

13   FORGOTTEN FEATURES
8.
Next Tick: Waiting for the DOM to Update

Vue gives us a super handy way for us to wait for the DOM to finish updating:

// Do something that will cause Vue to re-render

changeTheDOM();

// Wait for the re-render to finish

await nextTick();

// Now we can check out the freshly minted DOM

inspectTheDOM();

Or if you're using the Options API:

await this.$nextTick();

A tick is a single render cycle. First, vue listens for any reactivity changes, then performs sev-
eral updates to the DOM in one batch. Then the next tick begins.

If you update something in your app that will change what is rendered, you have to wait until
the next tick before that change shows up.

VUE TIPS COLLECTION    14

 9.
A simpler way to pass lots of props

Instead of passing in tons of props to a component individually:

<template>
<User
:name="user.name"
:profile="user.profile"
:twitter="user.twitter"
:location="user.location"
:framework="user.framework === 'Vue' ? 'Number one' : 'Number two'"
/>
</template>

You can take a whole object and have all of its properties automatically bound to the compo-
nent as props:

<template>
<User v-bind="user"/>
</template>
<script setup>
import User from './User.vue';

const user = {
name: 'Anakin',
profile: 'ani-profile.jpg',
twitter: '@TatooineJedi',
location: 'Undisclosed',
framework: 'Vue',
};
</script>

15   FORGOTTEN FEATURES
This also works with v-on if you have a lot of event handlers:

<template>
<User v-on="userEventHandlers"/>
</template>
<script setup>
import User from './User.vue';

const userEventHandlers = {
updateName(newName) {
// ...
},
deleteUser() {
// ...
},
addFriend(friend) {
// ...
}
};
</script>

Here, the name of each method needs to match the name of the event. eg. updateName is
called to handle the update-name event.

VUE TIPS COLLECTION    16

 10.
Restrict a prop to a list of types

With the Composition API we get fantastic TypeScript support, so this is quite straightforward:

defineProps<{
src: string;
style: 'square' | 'rounded';
}>();

Doing this in the Options API is more complicated, and not as powerful as TypeScript.

Using the validator option in a prop definition you can restrict a prop to a specific set of
values:

export default {
name: 'Image',
props: {
src: {
type: String,
},
style: {
type: String,
validator: s => ['square', 'rounded'].includes(s)
}
}
};

17   FORGOTTEN FEATURES
This validator function takes in a prop and returns either true or false — if the prop is
valid or not.

I often restrict props like this when I need more options than a boolean will allow but still
want to restrict what can be set.

Button types or alert types (info, success, danger, warning) are some of the most common uses
— at least in what I work on. Colours, too, are a really great use case for this.

VUE TIPS COLLECTION    18

 11.
toRef default value

You’ve been using toRef for a while, but did you know you can also supply a default value?

const bank = reactive({

Rand: 3400,
Egwene: 20,
Matrim: 230340,
Padan: -20340,
})

// toRef(object, property, default)

const myBankAccount = toRef(bank, 'Michael', 1000 * 1000);

Probably the easiest way to become a millionaire.

19   FORGOTTEN FEATURES
12.
Special CSS pseudo-selectors in Vue

If you want some styles to apply specifically to slot content, you can do that with the
:slotted pseudo-selector:

<style scoped>
/* Add margin to <p> tags within the slot */
:slotted(p) {
margin: 15px 5px;
}
</style>

You can also use :global to have styles apply to global scope, even within the
<style scoped> block:

<style scoped>
:global(body) {
margin: 0;
padding: 0;
font-family: sans-serif;
}
</style>

Of course, if you have lots of global styles you want to add, it’s probably easier to just add a
second <style> block:

VUE TIPS COLLECTION    20

 <style scoped>
/* Add margin to <p> tags within the slot */
:slotted(p) {
margin: 15px 5px;
}
</style>

<style>
body {
margin: 0;
padding: 0;
font-family: sans-serif;
}
</style>

Check out the docs for more info.

21   FORGOTTEN FEATURES
13.
How to watch anything in your component

It took me a very long time to realize this, but anything in your component that is reactive can
be watched. This includes computed props as well:

const first = ref('Michael');

const last = ref('Thiessen');
const fullName = computed(() => '${first.value} ${last.value}');

watchEffect(() => console.log(fullName.value));

Maybe it’s just me, but for some reason this wasn’t all that intuitive at first for me.

With the Options API it looks like this:

export default {
computed: {
someComputedProperty() {
// Update the computed prop
},
},
watch: {
someComputedProperty() {
// Do something when the computed prop is updated
}
}
};

You can watch:

• computed props
• props
• nested values

VUE TIPS COLLECTION    22

 14.
Watching Nested Values

You may not have known this, but you can easily watch nested values directly when using the
Options API, just by using quotes:

watch: {
'$route.query.id'() {
// ...
}
}

This is really useful for working with deeply nested objects!

We can also watch nested values using the Composition API:

watch(
() => value.that.is.really.nested,
() => {
// ...
}
);

23   FORGOTTEN FEATURES
15.
Watching Arrays and Objects

The trickiest part of using a watcher is that sometimes it doesn’t seem to trigger correctly.

Usually, this is because you’re trying to watch an Array or an Object but didn’t set deep
to true :

watch(
colours,
() => {
console.log('The list of colours has changed!');
},
{
deep: true,
}
);

When using the Options API it would look like this:

export default {
name: 'ColourChange',
props: {
colours: {
type: Array,
required: true,
},
},
watch: {
// Use the object syntax instead of just a method
colours: {
// This will let Vue know to look inside the array
deep: true,

VUE TIPS COLLECTION    24

 // We have to move our method to a handler field
handler()
console.log('The list of colours has changed!');
}
}
}
}

25   FORGOTTEN FEATURES
16.
Vue to Web Component in 3 Easy Steps

Here’s how you can create web components in Vue.

First, create the custom element from a Vue component using defineCustomElement:

import { defineCustomElement } from 'vue';

import MyVueComponent from './MyVueComponent.vue';

const customElement = defineCustomElement(MyVueComponent);

Second, register the custom element with the DOM:

customElements.define('my-vue-component', customElement);

Third, use the custom element in your HTML:

<html>
<head></head>
<body>
<my-vue-component></my-vue-component>
</body>
</html>

Now you’ve got a custom web component that doesn’t need a framework and can run natively
in the browser! Check out the docs for more details on how this works.

VUE TIPS COLLECTION    26

2 Slots and
Reusability
Slots are the most powerful feature in Vue. They let
us create more flexible and reusable components.
17.
6 Levels of Reusability

There are six different levels of reusability that you can use in your components.

Each level increases your ability to reuse code.

These levels are the focus of my course, Reusable Components.

Here are the six levels of reusability:

1. Templating — Reusing code by wrapping it up inside of a component

2. Configuration — Using configuration props to allow for varying behaviou

3. Adaptability — Allowing components to become future-proof

4. Inversion — Letting other components control the process

5. Extension — Using reusability throughout our component

6. Nesting — Creating powerful hierarchies of components

I cover this in more detail in this excerpt from the course.

VUE TIPS COLLECTION    28

 18.
Nesting slots

As you start creating more abstractions with Vue, you may need to begin nesting your slots:

<!-- Parent.vue -->

<template>
<Child>
<!-- We take the content from the grand-parent slot
and render it inside the child's slot -->
<slot />
</Child>
</template>

This works similarly to how you would catch an error and then re-throw it using a try...
catch block:

try {
// Catch the error
reallyRiskyOperation();
} (e) {
// Then re-throw as something else for the next
// layer to catch and handle
throw new ThisDidntWorkError('Heh, sorry');
}

29    SLOTS AND REUSABILITY

Normally when using a slot we just render the content that’s provided to us:

<template>
<div>
<!-- Nothing to see here, just a regular slot -->
<slot />
</div>
</template>

But if we don’t want to render it in this component and instead pass it down again, we render
the slot content inside of another slot:

<template>
<Child>
<!-- This is the same as the previous code example,
but instead of a 'div' we render into a component. -->
<slot />
</Child>
</template>

VUE TIPS COLLECTION    30

 19.
Recursive slots

I decided to see if I could make a v-for component using only the template. Along the way,
I discovered how to use slots recursively, too.

This is what the component looks like:

<!-- VFor.vue -->

<template>
<div>
<!-- Render the first item -->
{{ list[0] }}
<!-- If we have more items, continue!
But leave off the item we just rendered -->
<v-for
v-if="list.length > 1"
:list="list.slice(1)"
/>
</div>
</template>

If you wanted to do this with scoped slots — and why wouldn’t you?! — it just takes a few
tweaks:

<template>
<div>
<!-- Pass the item into the slot to be rendered -->
<slot v-bind:item="list[0]">
<!-- Default -->
{{ list[0] }}
</slot>

31    SLOTS AND REUSABILITY

 <v-for
v-if="list.length > 1"
:list="list.slice(1)"
>
<!-- Recursively pass down scoped slot -->
<template v-slot="{ item }">
<slot v-bind:item="item" />
</template>
</v-for>
</div>
</template>

Here is how this component is used:

<template>
<div>
<!-- Regular list -->
<v-for :list="list" />

<!-- List with bolded items -->

<v-for :list="list">
<template v-slot="{ item }">
<strong>{{ item }}</strong>
</template>
</v-for>
</div>
</template>

For a more detailed explanation of this example and nested slots, check out my blog post on it.

VUE TIPS COLLECTION    32

 20.
Conditionally Rendering Slots

First, I’ll show you how, then we’ll get into why you’d want to hide slots.

Every Vue component has a special $slots object with all of your slots in it. The default slot
has the key defaults , and any named slots use their name as the key:

const $slots = {
default: <default slot>,
icon: <icon slot>,
button: <button slot>,
};

But this $slots object only has the slots that are applied to the component, not every slot
that is defined.

Take this component that defines several slots, including a couple named ones:

<!-- Slots.vue -->

<template>
<div>
<h2>Here are some slots</h2>
<slot />
<slot name="second" />
<slot name="third" />
</div>
</template>

If we only apply one slot to the component, only that slot will show up in our $slots object:

33    SLOTS AND REUSABILITY

 <template>
<Slots>
<template #second>
This will be applied to the second slot.
</template>
</Slots>
</template>

$slots = { second: <vnode> }

We can use this in our components to detect which slots have been applied to the component,
for example, by hiding the wrapper element for the slot:

<template>
<div>
<h2>A wrapped slot</h2>
<div v-if="$slots.default" class="styles">
<slot />
</div>
</div>
</template>

Now the wrapper div that applies the styling will only be rendered if we actually fill that
slot with something. If we don’t use the v-if , we will have an empty and unnecessary div
if we don’t have a slot. Depending on what styling that div has, this could mess up our lay-
out and make things look weird.

So why do we want to be able to conditionally render slots?

There are three main reasons to use a conditional slot:

1. When using wrapper `div’s to add default styles

2. The slot is empty
3. If we’re combining default content with nested slots

For example, when we’re adding default styles, we’re adding a div around a slot:

VUE TIPS COLLECTION    34

 <template>
<div>
<h2>This is a pretty great component, amirite?</h2>
<div class="default-styling">
<slot >
</div>
<button @click="$emit('click')">Click me!</button>
</div>
</template>

However, if no content is applied to that slot by the parent component, we’ll end up with an
empty div rendered to the page:

<div>
<h2>This is a pretty great component, amirite?</h2>
<div class="default-styling">
<!-- No content in the slot, but this div
is still rendered. Oops. -->
</div>
<button @click="$emit('click')">Click me!</button>
</div>

Adding that v-if on the wrapping div solves the problem though. No content applied to
the slot? No problem:

<div>
<h2>This is a pretty great component, amirite?</h2>
<button @click="$emit('click')">Click me!</button>
</div>

Here’s a Codesandbox with a working demo if you want to take a look.

I wrote more tips on slots in this article: Tips to Supercharge Your Slots (Named, Scoped, and
Dynamic)

35    SLOTS AND REUSABILITY

21.
Using default and named slots

Let’s say we’re building an If component and we want to use it in two main ways — with a
default slot, or with two named slots.

Just the default slot:

<If :val="putConditionHere">
Renders only if it's true
</If>

Or using the named slots to access both branches:

<If :val="putConditionHere">
<template #true>
Renders only if it's true
</template>
<template #false>
Renders only if the condition is false
</template>
</If>

This is how we’d have to arrange the slots in order to make this work:

<template>
<slot v-if="val" />

<template v-if="!$slots.default">
<slot v-if="val" name="true" />
<slot v-if="!val" name="false" />
</template>
</template>

VUE TIPS COLLECTION    36

 You’ll notice we use a template to group the named slots. We’re also checking $slots to
see if we’ve put anything in the default slot or not.

We need to do this, otherwise we’ll render the default and true slots whenever our
condition is true, which isn’t what we want! We want these to be mutually exclusive — you can
either use the default slot or the named true slot.

Now, we can use it in either way.

Just the default slot to access the true branch, or using two named slots to access both the true
and false branches.

37    SLOTS AND REUSABILITY

22.
Default Content with Nested Slots

If you have multiple levels of nested slots, it’s possible to have defaults at each level:

<!-- Parent.vue -->

<template>
<Child>
<slot>
We're in the Parent!
</slot>
</Child>
</template>

<!-- Child.vue -->

<template>
<div>
<slot>
We're in the Child!
</slot>
</div>
</template>

The slot content provided at the highest point in the hierarchy will override everything below it.

If we render Parent , it will always display We’re in the Parent . But if we render just
the Child component, we get We’re in the Child !. And if the component rendering the
Parent component provides slot content, that will take precedence over everything:

<!-- Grandparent.vue -->

<template>
<Parent>
Haha this content rules them all!
</Parent>
</template>

VUE TIPS COLLECTION    38

 23.
Default Content with Slots

You can provide fallback content for a slot, in case no content is provided:

<!-- Child.vue -->

<template>
<div>
<slot>
Hey! You forgot to put something in the slot!
</slot>
</div>
</template>

This content can be anything, even a whole complex component that provides default
behaviour:

<!-- Child.vue -->

<template>
<div>
<slot name="search">
<!-- Can be overridden with more advanced functionality -->
<BasicSearchFunctionality />
</slot>
</div>
</template>

39    SLOTS AND REUSABILITY

24.
The limitations of props

Props are helpful, but they have two glaring issues:

1. Impossible to pass markup*

2. Not that flexible

*not technically impossible, but not something you want to do.

The solution to these two problems is the same, but we’ll get there in a second.

Many components you create are contentless components. They provide a container, and
you have to supply the content. Think of a button, a menu, an accordion, or a card component:

<Card title="Shrimp Tempura">

<img src="picOfShrimp.jpg" />
<div>
<p>Here are some words about tempura.</p>
<p>How can you go wrong with fried food?</p>
</div>
<a href="www.michaelnthiessen.com/shrimp-tempura">
Read more about Shrimp Tempura
</a>
</Card>

You can often pass this content in as a regular String . But many times, you want to pass in a
whole chunk of HTML, maybe even a component or two.

You can’t do that with props.*

*again, yes, you could do this, but you’ll definitely regret it.

Props also require that you plan for all future use cases of the component. If your Button
component only allows two values for type , you can’t just use a third without modifying the
Button :

VUE TIPS COLLECTION    40

 <!-- You just have to *believe* it will work -->
<Button type="AWESOME" />

The component doesn’t allow for that...

<!-- Button.vue -->

<script setup>
defineProps<{
type: 'Primary' | 'Secondary' // AWESOME is not an option here
}>();
</script>

I’m not a psychic, and I’m guessing you aren’t either.

The solution to these problems?

I think I gave it away with my card example above...

...slots!

Slots allow you to pass in whatever markup and components you want, and they also are
relatively open-ended, giving you lots of flexibility. This is why in many cases, slots are simply
better than props.

41    SLOTS AND REUSABILITY

25.
Shorthand for named slots

Named slots also have a shorthand syntax, one that’s much nicer to look at.

Instead of writing this:

<DataTable>
<template v-slot:header>
<TableHeader />
</template>
</DataTable>

We can write this:

<DataTable>
<template #header>
<TableHeader />
</template>
</DataTable>

Not a huge difference, but a little cleaner for sure. I think the # character is easier to pick out
than v-slot when reading code.

VUE TIPS COLLECTION    42

 26.
Slot Transitions

It’s possible to use transitions with slot content, but there’s one key to making them work
smoothly:

<!-- SlotWithTransition.vue -->

<template>
<!-- Creating the base slot with a transition -->
<transition name="fade" mode="out-in">
<slot></slot>
</transition>
</template>

Always make sure that content provided to the slot is keyed.

This helps Vue keep track of when to trigger the transition:

<template>
<SlotWithTransition>
<div v-if="isThisTrue" key="true">
This is true.
</div>
<div v-else key="false">
This is false.
</div>
</SlotWithTransition>
</template>

43    SLOTS AND REUSABILITY

27.
Reusable Components Aren’t What You Think

Reusable components don’t have to be big or complex things.

I often make small and short components reusable.

Because I’m not re-writing this code all over the place, updating it becomes much easier, and
I can make sure that every OverflowMenu looks and works exactly the same — because they
are the same!

<!-- OverflowMenu.vue -->

<template>
<Menu>
<!-- Add a custom button to trigger our Menu -->
<template #button v-slot="bind">
<!-- U se bind to pass click handlers,
a11y attributes, etc. -->
<Button v-bind="bind">
<!-- U se our own "..." icon and no text
for this button -->
<template #icon>
<svg src="./ellipsis.svg" />
</template>
</Button>
</template>
</Menu>
</template>

VUE TIPS COLLECTION    44

 Here we take a Menu component but add a ‘...’ (ellipsis) icon to the button that triggers it to
open.

It almost seems like it’s not worth making a reusable component out of this because it’s only a
few lines. Can’t we just add the icon every time we want to use a Menu like this?

But this OverflowMenu will be used dozens of times, and now if we want to update the icon
or its behaviour, we can do it very quickly. And using it is much simpler too!

<template>
<OverflowMenu
:menu-items="items"
@click="handleMenuClick"
/>
</template>

45    SLOTS AND REUSABILITY

28.
Splitting Slots

Let’s take a slot and split it into two slots:

<!-- Parent.vue -->

<template>
<Child>
<!--Splitting a slot into multiple requires
a conditional. This allows you to branch
into however many slots you want -->
<slot v-if="left" name="left" />
<slot v-else name="right" />
</Child>
</template>

Our Child component only accepts one slot, but the Parent component accepts two.

Here, the Parent component switches between which slot it uses based on the value of left .

We can also use default slot content, if one or both of the Parent slots have no content:

<!-- Parent.vue -->

<template>
<Child>
<slot v-if="left" name="left">
<!-- Default content works like you'd expect -->
<div key="left">Default left</div>
</slot>
<slot v-else name="right">
<div key="right">Default Right</div>
</slot>
</Child>
</template>

VUE TIPS COLLECTION    46

 29.
Improve reusability by converting template props
into slots

One kind of prop, a template prop, can be directly converted into slots without very much
work.

This makes your component more reusable.

The text prop here is a template prop, because it is only ever used in the template:

<template>
<button @click="$emit('click')">
{{ text }}
</button>
</template>
<script setup>
const props = defineProps({
text: {
type: String,
required: true,
},
});
defineEmits(['click']);
</script>

It doesn’t get used in any calculations or passed as a prop anywhere. Instead, it just gets direct-
ly interpolated and rendered to the page.

47    SLOTS AND REUSABILITY

These props can be directly replaced with slots:

<template>
<button @click="$emit('click')">
<slot />
</button>
</template>
<script setup>
defineEmits(['click']);
</script>

This sort of cleans up the code, but more importantly, it allows us to be more flexible with how
the component can be used.

With a prop we have to use the component like this:

<Button text="Click me" @click="handleClick" />

But with a slot, we can add in whatever we want:

<Button @click="handleClick">
Click on <strong>this</strong> button
</Button>

VUE TIPS COLLECTION    48

 30.
Understanding scoped slots

Here’s the best way to think about scoped slots:

Scoped slots are like functions that are passed to a child component that returns
HTML.

Once the template is compiled, they are functions that return HTML (technically vnodes ) that
the parent passes to the child.

Here’s a simple list that uses a scoped slot to customize how we render each item:

<!-- Parent.vue -->

<template>
<ScopedSlotList :items="items">
<template v-slot="{ item }">
<!-- Make it bold, just for fun -->
<strong>{{ item }}</strong>
</template>
</ScopedSlotList>
</template>

<!-- ScopedSlotList.vue -->

<template>
<ul>
<li
v-for="item in items"
:key="item"
>
<slot :item="item" />
</li>
</ul>
</template>

49    SLOTS AND REUSABILITY

We can rewrite this example to use a function instead of a scoped slot:

<!-- Parent.vue -->

<template>
<ScopedSlotList
:items="items"
:scoped-slot="(item) => '<strong>${item}</strong>'"
>
</template>

<!-- ScopedSlotList.vue -->

<template>
<ul>
<li
v-for="item in items"
:key="item"
v-html="scopedSlot(item)"
/>
</ul>
</template>

VUE TIPS COLLECTION    50

3 Logic
Lore
Covering the Composition API, Options API,
and composables.
31.
A bunch of composable mini tips

Yes, mini tips within a tip. It’s meta.

Here they are:

•  tart with the end in mind, and write the return first. Once you know how you want the
S
composable to be used, filling in the implementation details is much easier.

•  se an options object as the parameter. This makes it easy to add new parameters in
U
the future without breaking anything, and you won’t mess up the ordering anymore.

•  eep them small. Embrace the UNIX philosophy and make sure each composable only
K
does one thing but does it well.

• Name them consistently: use ______ , create ______ , on ______

•  lways make sure your reactivity is hooked up before any async logic. By using a ref
A
of null , you can update those values later when your logic completes. No need to
await around.

•  se effectScope to group effects if you have lots of them in your composable.

U
This makes cleaning up your reactivity a lot simpler. If you have large objects, use
shallowRef instead to prevent Vue from recursively making the whole thing reac-
tive. Of course, you’ll need to use triggerRef to trigger any reactive effects for it,
but it can improve performance.

Some tips on making your composables more flexible:

• If you’re using a watch , make immediate and flush configurable

• Accept both refs and primitive values as inputs. By passing the variable through
ref , you’ll either reuse the existing ref or create a new one.

•  he same trick works with unref if what you need in your composable is a primitive
T
and not a ref .

VUE TIPS COLLECTION    52

 32.
Configuring Composables with the Options Object

We can make our composables more reusable by passing in an object that contains all of the
configuration options for how we want the composable to behave:

const state = ref({ email: '' });

const { history, undo, redo } = useRefHistory(state, {

// Track history recursively
deep: true,
// Limit how many changes we save
capacity: 10,
});

We use an object here instead of a long list of parameters:

const { history, undo, redo } = useRefHistory(state, true, 10));

Using an options object instead of parameters gives us several benefits.

First, it’s self-documenting. We have the name of the parameter right beside the value, so we
never forget what each value is doing.

We can also create a type for the entire options object:

export type RefHistoryOptions {

deep?: boolean;
capacity?: number;
};

53   LOGIC LORE
 export type RefHistoryReturn {
history: Ref;
undo: () => void;
redo: () => void;
};

export function useRefHistory(

ref: Ref,
options: RefHistoryOptions
): RefHistoryReturn {};

Second, we don’t need to worry about ordering or unused options. The more potential
edge cases we cover with a composable, the more options we’ll have. But we usually only need
to worry about a couple of them at one time — they’re all optional.

Third, it’s much easier to add new options. Because the order doesn’t matter and none of
the options are required, adding a new capability to our composable won’t break anything. We
simply add it to the list of possible options and carry on.

The pattern doesn’t require a lot of work to implement, either:

export function useRefHistory(ref, options) {

const {
deep = false,
capacity = Infinity,
} = options;

// ...
};

First, we pass in the options object as the last parameter. This makes it possible to have the
options object itself as an optional parameter.

The required params come first. Typically, there will only be one or two. More parameters is a
code smell, and likely means that your composable is trying to do too much.

VUE TIPS COLLECTION    54

 The required parameter (or parameters) is very often a Ref , or a MaybeRef if we’re also
implementing the Flexible Arguments Pattern.

We then access the options by destructuring.

Doing this gives us a really clean and readable way of providing defaults. Remember, these are
options so they should all have defaults. If the values are required they should likely have

This helps to clarify what options are being used in this composable. It’s not uncommon for
one composable to use another composable, and in that case some of the options are simply
passed along to the inner composable:

export function useRefHistory(ref, options) {

const {
deep = false,
capacity = Infinity,
...otherOptions,
} = options;

// Pass along some options we're not using directly

useSomeOtherComposable(otherOptions);
};

55   LOGIC LORE
33.
Example of a Composable Using the Options
Object Pattern

Let’s create a useEvent composable that will make it easier to add event listeners.

We’ll use the EventTarget.addEventListener method, which require the event and
handler parameters. These are the first two required parameters:

export function useEvent(event, handler) {};

But we also need to know which element to target. Since we can default to the window , we’ll
make this our first option:

export function useEvent(event, handler, options) {

// Default to targeting the window
const { target = window } = options;
};

Then we’ll add in onMounted and onBeforeUnmount hooks to setup and clean up our
event:

import { onMounted, onBeforeUnmount } from 'vue';

export function useEvent(event, handler, options) {

// Default to targeting the window
const { target = window } = options;

onMounted(() => {
target.addEventListener(event, handler);
});

VUE TIPS COLLECTION    56

 onBeforeUnmount(() => {
target.removeEventListener(event, handler);
});
};

We can use the composable like this:

import useEvent from '~/composables/useEvent.js';

// Triggers anytime you click in the window

useEvent('click', () => console.log('You clicked the window!'));

The addEventListener method can also take extra options, so let’s add support for that, too:

import { onMounted, onBeforeUnmount } from 'vue';

export function useEvent(event, handler, options) {

// Default to targeting the window
const {
target = window,
...listenerOptions
} = options;

onMounted(() => {
target.addEventListener(event, handler, listenerOptions);
});

onBeforeUnmount(() => {
target.removeEventListener(event, handler, listenerOptions);
});
};

57   LOGIC LORE
We keep listenerOptions as a pass-through, so we’re not coupling our composable with
the addEventListener method. Beyond hooking up the event, we don’t really care how it
works, so there’s no point in interfering here.

Now we can take advantage of those extra options:

import useEvent from '~/composables/useEvent.js';

// Triggers only the first time you click in the window

useEvent(
'click',
() => console.log('First time clicking the window!'),
{
once: true,
}
);

This is a pretty basic composable, but by using the Options Object Pattern it’s easily configu-
rable and extendable to cover a wide swath of use cases.

VUE TIPS COLLECTION    58

 34.
The Right Number of Options for Composables

The Options Object Pattern can be really useful, but it can cause trouble if used too much.

If you have only a couple options for your composable, it may be simpler to leave it out:

import { onMounted, onBeforeUnmount } from 'vue';

export function useEvent(event, handler, target = window) {

// No point in having an options object

onMounted(() => {
target.addEventListener(event, handler);
});

onBeforeUnmount(() => {
target.removeEventListener(event, handler);
});
};

If we need to target a different element, like a button, we can use it like this:

import useEvent from '~/composables/useEvent.js';

// Triggers anytime you click the button

useEvent(
'click',
() => console.log('You clicked the button!'),
buttonElement
);

59   LOGIC LORE
But, if we want to add more options in the future, we break this usage because we’ve changed
the function signature:

before: useEvent(event, handler, target)

after: useEvent(event, handler, options)

It’s a design choice you’ll have to make. Starting with a small options object prevents breaking,
but adds a small amount of complexity to your composable.

But what if you have lots of options?

Since all of the options are optional, the sheer number of options is never really a problem
when it comes to using a composable. Further, we can organize the options into sub objects if
we really felt the need.

With the w composable we can group all the listenerOptions into their own object to
help organize things:

import { onMounted, onBeforeUnmount } from 'vue';

export function useEvent = (event, handler, options) => {

// Default to targeting the window
const {
target = window,
listener,
} = options;

onMounted(() => {
target.addEventListener(event, handler, listener);
});

onBeforeUnmount(() => {
target.removeEventListener(event, handler, listener);
});
};

VUE TIPS COLLECTION    60

 The usage now becomes this:

import useEvent from '~/composables/useEvent.js';

// Triggers only the first time you click in the window

useEvent(
'click',
() => console.log('First time clicking the window!'),
{
listener: {
once: true,
}
}
);

61   LOGIC LORE
35.
Async Without Await

Using async logic with the composition API can be tricky at times.

We need to put things in the correct order, or the await keyword will mess things up with our
reactivity.

But with the Async Without Await pattern, we don’t need to worry about all of this:

const title = ref('Basic Title');

// We can place this async function wherever we want
const { state } = useAsyncState(fetchData());
const betterTitle = computed(() => `${title.value}!`);

Here’s how this works:

1. We hook up all of our refs synchronously

2. Updates happen asynchronously in the background

3. Because of reactivity, everything “just works”

Here’s a basic sketch of what the useAsyncState composable from VueUse is doing to im-
plement this:

export default useAsyncState(promise) {

// 1. Create state ref synchronously
const state = ref(null);

const execute = async () => {

// 3. Reactivity will update this when it resolves
state.value = await promise;
}

VUE TIPS COLLECTION    62

 // 2. Execute promise asynchronously in the background
execute();
return state;
}

63   LOGIC LORE
36.
Dynamic Returns

A composable can either return a single value or an object of values. Typically, these values
are refs .

But we can also dynamically switch between the two depending on what we want to use the
composable for:

// Grab only the single value

const now = useNow()

// Get more granular access to the composable

const {
now,
pause,
resume
} = useNow({ controls: true })

This is great because we may only need a single value most of the time. So why complicate the
interface for the main use case?

But by dynamically providing the full object of refs , we allow for more advanced use cases
as well. Even if they are rarely used.

Here is how we might implement that:

export default useNow(opts) {

const {
controls = false,
} = opts;

// Do some things in your composable

VUE TIPS COLLECTION    64

 if (controls) {
return { now, pause, resume };
} else {
return now;
}
}

65   LOGIC LORE
37.
Flexible Arguments

Sometimes we have a ref , that we want to use with our composable. Sometimes we just
have the raw data.

Wouldn’t it be nice if it didn’t matter what we already had? Then we could use our compos-
ables and it would just work?

Here’s an example using the useTitle composable from VueUse:

// We have a ref already

const titleRef = ref('This is the title of the page');
useTitle(titleRef);

// We just have the string

const title = 'This is the title of the page';
const titleRef = useTitle(title);

We can do this by implementing the Flexible Arguments pattern:

export function useTitle(maybeRef) {

const titleRef = ref(maybeRef);

// Use titleRef in the composable

}

The ref , function will either create a ref for us, or return a ref if we give it one.

VUE TIPS COLLECTION    66

 This means that we can pass it either type and we know we’ll get a ref back.

The opposite is true with the unref function. If we need to use a raw primitive value rather
than a ref in our composable, we can use unref to achieve a similar result.

export function useTitle(maybeRef) {

const titleString = unref(maybeRef);

// Use titleString in the composable

}

67   LOGIC LORE
38.
Ref vs. Reactive

Is it better to use ref or reactive when using the Composition API?

Here are a few situations where ref is better than reactive.

Using ref on objects makes it clear where an object is reactive and where it’s just a plain object:

// I can expect this ref to update reactively

if (burger.value.lettuce) {
// ...
}

// I have no clue if this value is reactive

if (burger.lettuce) {
// ...
}

When using one of the watch methods, refs are automatically unwrapped, so they’re nicer to use:

// Ref
const refBurger = ref({ lettuce: true });
watch(
// Not much, but it's a bit simpler to work with
refBurger,
() => console.log("The burger has changed"),
{ deep: true }
);

VUE TIPS COLLECTION    68

 // Reactive
const reactiveBurger = reactive({ lettuce: true });
watch(
reactiveBurger,
() => console.log("The burger has changed"),
);

One last reason why refs make more sense to me — you can put refs into a reactive
object. This lets you compose reactive objects out of refs and still use the underlying
refs directly:

const lettuce = ref(true);

const burger = reactive({
// The ref becomes a property of the reactive object
lettuce,
});

// We can watch the reactive object

watchEffect(() => console.log(burger.lettuce));

// We can also watch the ref directly

watch(lettuce, () => console.log("lettuce has changed"));

setTimeout(() => {
// Updating the ref directly will trigger both watchers
// This will log: 'false', 'lettuce has changed'
lettuce.value = false;
}, 500);

I wrote a very comprehensive article comparing the two even further if you want to go deeper.

69   LOGIC LORE
39.
Too Many Props/Options is a Smell

Although the total number of options (and required params) isn’t itself a problem, it is an indi-
cation that the design isn’t quite as good as it could be.

Chances are that your composable (or component) is trying to do more than one thing, and
should instead be separated into several composables. The point of composables is that they
each do one specific thing really well, and can be composed together to produce more com-
plex functionality.

Imagine that we have a useEvent composable that looks like this:

import { ref, onMounted, onBeforeUnmount } from 'vue';

export function useEvent(event, handler, interval, options) => {

// Default to targeting the window
const {
target = window,
...listenerOptions
} = options;

const startInterval = () => {

setInterval(handler, interval);
};

onMounted(() => {
target.addEventListener(event, startInterval, listenerOptions);
});

onBeforeUnmount(() => {
target.removeEventListener(event, startInterval, listenerOptions);
});
};

VUE TIPS COLLECTION    70

 We’d use it like this. As soon as the button is clicked, we’ll log to the console every second:

import useEvent from '~/composables/useEvent.js';

useEvent(
'click',
() => console.log('Logging every second'),
1000,
{
target: buttonElement,
}
);

We can see that it’s doing two separate things:

1. Listening for events

2. Setting up an interval

Instead of including the interval functionality in our useEvent composable, it makes more
sense to break it out into a second composable:

export function useInterval(callback, options) {

const { interval = 1000 } = options;
const intervalId = setInterval(callback, interval);

return () => clearInterval(intervalId);

};

Our useEvent composable becomes simpler:

import { onMounted, onBeforeUnmount } from 'vue';

export function useEvent(event, handler, options) {

// Default to targeting the window

71   LOGIC LORE
 const {
target = window,
...listenerOptions
} = options;

onMounted(() => {
target.addEventListener(event, handler, listenerOptions);
});

onBeforeUnmount(() => {
target.removeEventListener(event, handler, listenerOptions);
});
};

And now we can compose the two together to get the desired effect:

import useEvent from '~/composables/useEvent.js';

import useInterval from '~/composables/useInterval.js';

useEvent(
'click',
() => useInterval(
() => console.log('Logging every second')
),
{
target: buttonElement,
}
);

When we click on the buttonElement , we call useInterval to set up the interval that will
log to the console every second.

VUE TIPS COLLECTION    72

 40.
Nesting Reactive Objects

Here’s a nuance to nesting reactive objects that’s tripped me up.

Nesting a ref in a reactive array keeps everything reactive as expected:

const arr = reactive([]);

arr.push(ref('hello'));
arr.push(ref('world'));

setTimeout(() => (arr[0].value = 'nothing'), 1000);

But putting this ref inside a non-reactive object breaks this reactivity:

const arr = reactive([]);

arr.push({
text: ref('hello'),
});
arr.push({
text: ref('world'),
});

setTimeout(() => (arr[0].value = 'nothing'), 1000);

I gave a hint in that last sentence — this is because it’s being wrapped in a non-reactive object.
The trail of reactivity goes cold once we hit this object, but only because we’re accessing the
text property through the non-reactive object.

73   LOGIC LORE
If we instead access the ref directly, we’re able to trigger a reactive update as expected:

const arr = reactive([]);

const one = ref('hello');

const two = ref('world');

arr.push({
text: one,
});
arr.push({
text: two,
});

// This triggers the update correctly

setTimeout(() => (one.value = 'nothing'), 1000);

Of course, this isn’t about refs in particular. All we need is to keep the reactivity alive, which we
can also achieve using reactive.

VUE TIPS COLLECTION    74

 41.
When ref and reactive work the same

It can be confusing to know whether or not to use ref or reactive .

Here are a few instances where they end up working basically the same.

When using watchEffect dependencies are tracked automatically, so there isn’t much dif-
ference between ref and reactive :

// Ref — just need to access through 'value' property

const refBurger = ref({ lettuce: true });
watchEffect(() => console.log(refBurger.value.lettuce);

// Reactive
const reactiveBurger = reactive({ lettuce: true });
watchEffect(() => console.log(reactiveBurger.lettuce));

Also, because refs are automatically unwrapped in the template, there is no difference
there:

<template>
<!-- Ref -->
{{ burger.lettuce }}

<!-- Reactive -->

{{ burger.lettuce }}
</template>

75   LOGIC LORE
If you destructure an object you’ll need to convert back to refs if you want reactivity:

// Using 'ref'
const { lettuce } = toRefs(burger.value);

// Using 'reactive'
const { lettuce } = toRefs(burger);

But if you have to convert everything to refs anyway, why not just use them to begin with?

VUE TIPS COLLECTION    76

 42.
Reassigning and Reactivity

Reactive values cannot be reassigned how you might expect:

const myReactiveArray = reactive([1, 2, 3]);

watchEffect(() => console.log(myReactiveArray));

// "[1, 2, 3]"

myReactiveArray = [4, 5, 6];

// The watcher never fires
// We've replaced it with an entirely new, non-reactive object

This is because the reference to the previous object is overwritten by the reference to the new
object. We don’t keep that reference around anywhere.

Vue developers for years have been tripped up by how reactivity works when reassigning val-
ues, especially with objects and arrays:

// You got a new array, awesome!

// ...but does it properly update your app?
myReactiveArray = [1, 2, 3];

This was a big issue with Vue 2 because of how the reactivity system worked. Vue 3 has mostly
solved this, but we’re still dealing with this issue when it comes to reactive versus ref .

The proxy-based reactivity system only works when we access properties on an

object.

I’m going to repeat that because it’s such an important piece of the reactivity puzzle.

77   LOGIC LORE
This also applies to refs, but this is made a little easier because of the standard .value prop-
erty that each ref has:

const myReactiveArray = ref([1, 2, 3]);

watchEffect(() => console.log(myReactiveArray.value));

// "[1, 2, 3]"

myReactiveArray.value = [4, 5, 6];

// "[4, 5, 6]"

VUE TIPS COLLECTION    78

 43.
Template Refs

Reassigning values can cause issues when using the simplest form of template refs:

<template>
<div>
<h1 ref="heading">This is my page</h1>
</div>
</template>

In this case, we can’t use a reactive object at all:

const heading = reactive(null);

watchEffect(() => console.log(heading));
// "null"

When the component is first instantiated, this will log out null , because heading has no
value yet. But when the component is mounted and our h1 is created, it will not trigger.

The heading object becomes a new object, and our watcher loses track of it. The reference
to the previous reactive object is overwritten.

We need to use a ref here:

const heading = ref(null);

watchEffect(() => console.log(heading.value));
// "null"

This time, when the component is mounted it will log out the element. This is because only a

79   LOGIC LORE
 ref can be reassigned in this way.

It is possible to use reactive in this scenario, but it requires a bit of extra syntax using func-
tion refs:

<template>
<div>
<h1
:ref="(el) => { heading.element = el }"
>
This is my page
</h1>
</div>
</template>

Then our script would be written as so, using the el property on our reactive object:

const heading = reactive({ el: null });

watchEffect(() => console.log(heading.el));
// "null"

VUE TIPS COLLECTION    80

 44.
Avoid Ref Soup

With reactive objects we can organize our state into objects instead of having a bunch of
refs floating around:

// Just a bunch a refs :/

const firstName = ref('Michael');
const lastName = ref('Thiessen');
const website = ref('michaelnthiessen.com');
const twitter = ref('@MichaelThiessen');

Passing around a single object instead of lots of refs is much easier, and helps to keep our
code organized:

// A single object to think about

const michael = reactive({
firstName: 'Michael',
lastName: 'Thiessen',
website: 'michaelnthiessen.com',
twitter: '@MichaelThiessen',
});

There’s also the added benefit that it’s much more readable.

When someone new comes to read this code, they know immediately that all of the values
inside of a single reactive object must be related somehow — otherwise, why would they
be together?

With a bunch a refs it’s much less clear as to how things are related and how they might work
together (or not).

81   LOGIC LORE
However, an even better solution for grouping related pieces of reactive state might be to cre-
ate a simple composable instead:

// Similar to defining a reactive object

const michael = usePerson({
firstName: 'Michael',
lastName: 'Thiessen',
website: 'michaelnthiessen.com',
twitter: '@MichaelThiessen',
});

// We usually return refs from composables, so we can destructure here

const { twitter } = michael;

This gives us the benefits of both worlds.

And if we need to add a method that modifies this state it can go in the composable. You can’t
do that with ref soup or a reactive object*.

*you can, but you should first stop and ask yourself if you should.

VUE TIPS COLLECTION    82

 45.
Composable Return Values

When you’re creating composables, here are some things you can do to make it easier to work
with their return values.

Return an object of refs, so that reactivity is preserved when destructuring:

// Composable
const useBurger = () => {
const lettuce = ref(true);
const ketchup = ref(true);

return {
lettuce,
ketchup,
};
};

// Component
setup() {

// We can destructure but still keep our reactivity

const { ketchup } = useBurger();

watchEffect(() => console.log(ketchup.value));

return {
ketchup,
removeKetchup: () => ketchup.value = false
};
},

83   LOGIC LORE
If you don’t want to destructure the values, you can always wrap it in reactive and it will be
converted to a reactive object:

// Component
setup() {
// Wrap in 'reactive' to make it a reactive object
const burger = reactive(useBurger());

watchEffect(() => console.log(burger.ketchup));

return {
burger,
removeKetchup: () => burger.ketchup = false
};
},

One great thing VueUse does is return a single value by default. If you happen to need more
granular control, you can pass in an option to get an object returned instead:

import { useTimestamp } from '@vueuse/core';

// Most of the time you only need the timestamp value

const timestamp = useTimestamp();

// But sometimes you may need more control

const {
timestamp,
pause,
resume,
} = useTimestamp({ controls: true });

I think presenting different interfaces based on how you need to use the composable is a bril-
liant pattern. This makes it simpler to work with while not sacrificing any precise control.

VUE TIPS COLLECTION    84

 46.
Global Properties

It’s possible to add global properties to your Vue app in both Vue 2 and Vue 3:

// Vue 3
const app = createApp({});
app.config.globalProperties.$myGlobal = 'globalpropertiesftw';

// Vue 2
Vue.prototype.$myGlobal = 'globalpropertiesftw';

I would recommend prefixing any global properties with a $ .

This helps prevent naming conflicts with other variables, and it’s a standard convention that
makes it easy to spot when a value is global.

This global property can be accessed directly off of any component when using the Options
API:

computed: {
getGlobalProperty() {
return this.$myGlobal;
},
},

Why can’t this be used with the composition API?

Because the composition API is designed to be context-free and has no access to this .

Instead, you can create a simple composable to access your globals:

85   LOGIC LORE
<script setup>
import useGlobals from './useGlobals';
const { $myGlobal } = useGlobals();
</script>

// useGlobals.js
export default () => ({
$myGlobal: 'globalpropertiesftw',
});

VUE TIPS COLLECTION    86

 47.
Inline Composables

You can define composables inline, keeping them in your SFC file:

<script setup>
const useCount = (i) => {
const count = ref(0);

const increment = () => count.value += 1;

const decrement = () => count.value -= 1;

return {
id: i,
count,
increment,
decrement,
};
};

const listOfCounters = [];

for (const i = 0; i < 10; i++) {
listOfCounters.push(useCount(i));
}
</script>
<template>
<div v-for="counter in listOfCounters" :key="counter.id">
<button @click="counter.decrement()">-</button>
{{ counter.count }}
<button @click="counter.increment()">+</button>
</div>
</template>

87   LOGIC LORE
But is there any point to doing this?

If you’re keeping your components focused on a specific task (and you should be), then it
stands to reason that the logic is also focused on a single task.

This means that if you wrap up all relevant logic into an inline composable, you’ve wrapped
up all — or nearly all — the logic that this component has:

<script setup>
// Create an inline composable
const useStuff = () => {
<all_our_logic>
};

// ...only to destructure most of it to use in our template

const {
value,
anotherValue,
eventHandler,
anotherEventHandler
} = useStuff();
</script>

At which point, we might as well write our logic without that unnecessary wrapper:

<script setup>
const value = ...
const anotherValue = ...
const eventHandler = ...
const anotherEventHandler = ...
</script>

However, if you have do have logic that can be encapsulated nicely within this inline
composable, it could make your code cleaner and easier to use.

Using lexical scoping to create more boundaries within your files helps you to understand and
think through your code, which is always helpful.

VUE TIPS COLLECTION    88

 48.
From Options to Composition — The Easy Way

You can use reactive to make the switch from the Options API a little easier:

// Options API
export default {
data() {
username: 'Michael',
access: 'superuser',
favouriteColour: 'blue',
},
methods: {
updateUsername(username) {
this.username = username;
},
}
};

We can get this working using the Composition API by copying and pasting everything over
using reactive :

// Composition API
setup() {
// Copy from data()
const state = reactive({
username: 'Michael',
access: 'superuser',
favouriteColour: 'blue',
});

89   LOGIC LORE
 // Copy from methods
updateUsername(username) {
state.username = username;
}

// Use toRefs so we can access values directly

return {
updateUsername,
...toRefs(state),
}
}

We also need to make sure we change this —› state when accessing reactive values, and
remove it entirely if we need to access updateUsername .

Now that it’s working, it’s much easier to continue refactoring using ref if you want to — or
just stick with reactive .

VUE TIPS COLLECTION    90

 49.
Shallow Refs

You can optimize the reactivity in your app by using shallowRef :

const user = shallowRef({

name: 'Michael',
friends: [
{
name: 'Travis',
friends: [
// ...
],
},
{
name: 'Matthew',
friends: [
// ...
],
},
]
});

Reactivity is only triggered when the value of the ref itself is changed:

// Triggers a reactive update

user.value = matthew;

91   LOGIC LORE
But modifying any of the nested properties won’t trigger anything:

// Nothing happens
user.value.name = 'Martin';

Adding deep reactivity to a large object can cost you a lot of performance, so this can be useful
for saving some CPU cycles.

You can also manually trigger a reactive update if it’s necessary:

// Log the user whenever it changes

watchEffect(() => console.log(user));

// Update nested state (no log happens)

user.value.name = 'Martin';

// Force a reactive update to trigger

triggerRef(user);

// [user object]

Here are the docs for shallowRef and triggerRef

VUE TIPS COLLECTION    92

 50.
Structuring Composables

To keep your composables — those extracted functions written using the Composition API —
neat and easy to read, here’s a way to organize the code.

1. Component and directives

2. provide and inject

3. defineProps , defineEmits , and defineExpose (when using script setup )

4. refs and reactive variables

5. Computed properties

6. Immediate watchers

7. Watchers

8. Lifecycle methods, in their correct order

9. Non-reactive state

10. Methods

11. Async code using await (or Promises if you’re into that sort of thing)

Why this order? Because it more or less follows the order of execution of the code.

It’s also based on the this linting rule.

The await needs to go at the end because most of your logic you’ll want to be registered before
the setup function returns. Anything after the await will only be executed asynchronously.

93   LOGIC LORE
51.
How to Watch Props for Changes

With the Composition API, we have several great options for watching props.

The recommended approach would be using either watch or watchEffect in your

script setup :

import { watch, watchEffect } from "vue";

const props = defineProps<{ count: number }>();
watch(
() => props.count,
(val) => {
console.log(val);
}
);
watchEffect(
() => console.log(props.count)
);

Script Setup + Composition API

When using the watch method, we have to provide a getter function instead of passing the
value directly. This is because the prop object itself is reactive, but the individual props are not.

You can test this for yourself by passing in the reactive prop object directly:

watch(
props,
(val) => {
console.log(val);
}
);

VUE TIPS COLLECTION    94

 The difference between watch and watchEffect is that watch requires us to specify
exactly what we’re watching, while watchEffect will simply watch every value that is used
inside of the method that we pass to it.

So we have a tradeoff between simplicity and flexibility.

Composition API + Options API

If you’re using the setup() function within the Options API, the only difference is in how we
specify the props. Otherwise, everything else works exactly the same:

import { watch, watchEffect } from "vue";

export default {
props: {
count: {
type: Number,
required: true,
},
},
setup(props) {
watch(
() => props.count,
(val) => {
console.log(val);
}
);

watchEffect(() => console.log(props.count));

},
};

95   LOGIC LORE
Options API
The process is straightforward with the Options API.

Just use the name of the prop as the name of the watcher, and you’re good to go!

export default {
props: {
count: {
type: Number,
required: true,
},
},
watch: {
count(val) {
console.log(val);
},
},
};

Although this syntax is simpler than the Composition API syntax, the tradeoff is that there is far
less flexibility.

If you want to watch multiple things at once, or have any fine-grained control over the depen-
dencies, the Composition API is much easier to use.

VUE TIPS COLLECTION    96

 52.
Wrapping Non-Reactive Code

You don’t always have to write a full-blown composable:

const set = reactive(new Set());

const values = computed(() => Array.from(set.values()));

set.add('hello');
set.add('world');

let counter = 1;
setInterval(() => {
set.add(counter);
counter += 1;
}, 1000);

Because Vue’s reactivity system uses proxies, this is a really easy way to take an existing object
and spice it up with some reactivity.

You can, of course, apply this to any other libraries that aren’t reactive.

Though you may need to watch out for edge cases here and there.

Check out a demo of this here.

97   LOGIC LORE
53.
Writable Computed Refs

Computed refs are cool and all, but did you know you can create writable computed refs?

const firstName = ref('');

const lastName = ref('');

const fullName = computed({

get: () => '${firstName.value} ${lastName.value}',
set: (val) => {
const split = val.split(' '); // ['Michael', 'Thiessen']
firstName.value = split[0]; // 'Michael'
lastName.value = split[1]; // 'Thiessen'
}
});

fullName.value = 'Michael Thiessen';

console.log(lastName.value); // 'Michael'

VUE TIPS COLLECTION    98

4 Nuxt
Nuggets
Everyone’s favourite Vue framework!
Well, at least it’s my favourite.
54.
Flatten Nuxt Content Routes

I wanted to organize my blog content into several folders:

• Articles: content/articles

• Newsletters: content/newsletters/

By default though, Nuxt Content would set up these routes to include those prefixes. But I want
all of my routes to be at the root level:

• Articles: michaelnthiessen.com/my-latest-article

• Newsletters: michaelnthiessen.com/most-recent-newsletter

We can do this manually for each Markdown file by overriding the _path property through
it’s frontmatter:

---
title: My Latest Article
date: today
_path: "/my-latest-article"
---

This is extremely tedious, error-prone, and generally annoying.

Luckily, we can write a simple Nitro plugin that will do this transform automatically.

VUE TIPS COLLECTION    100

 Create a content.ts file in server/plugins/ :

export default defineNitroPlugin((nitroApp) => {

nitroApp.hooks.hook('content:file:afterParse', (file) => {
for (const prefix of ['/articles', '/newsletters']) {
if (file._path.startsWith(prefix)) {
// Keep the prefix so we can query based on it still
file._original_dir = prefix;
// Remove prefix from path
file._path = file._path.replace(prefix, '');
}
}
});
});

Nitro is the server that Nuxt uses internally. We can hook into it’s processing pipeline and do a
bit of tweaking.

However, doing this breaks queryContent calls if we’re filtering based on the path, since
queryContent is looking at the _path property we’ve just modified. This is why we want
to keep that original directory around.

We can modify our queryContent calls to filter on this new _original_dir property:

// Before
queryContent('/articles')

// After
queryContent()
.where({
_original_dir: { $eq: '/articles' },
});

Pro tip: use nuxi clean to force Nuxt Content to re-fetch and re-transform all of your con-
tent.

101   NUXT NUGGETS
55.
Auto-imports in Nuxt 3

In Nuxt 3, instead of importing all of your dependencies like this:

// Part of my blog
import BasicLayout from './BasicLayout.vue';
import Footer from '../components/Footer';
import Subscribe from '../components/Subscribe';
import LandingMat from '../components/LandingMat';
import Logo from '../icons/Logo';
import LogoClip from '../icons/LogoClip';
import TriangleShape from '../icons/TriangleShape';
import SquareShape from '../icons/SquareShape';

You import them like this:

// ...just kidding. No imports needed!

Just use your components, composables, or layouts where you need them, and Nuxt takes care
of the rest.

It may seem like a small thing, but auto-imports in Nuxt 3 make the whole developer experi-
ence so much nicer. It only imports what you need, when you need it.

This makes your app much faster as well!

Yes, your dependencies are now less explicit. But if you keep your components and compos-
ables small enough it shouldn’t matter that much. You should still be able to see pretty quickly
what’s going on in your application.

VUE TIPS COLLECTION    102

 56.
Nuxt Content Queries

Nuxt Content 2 gives us an effortless way to query our content using the queryContent
method:

// composables/useArticles.js

export default () =>

queryContent('articles')
.where({
// Optional fields that may be true or non-existent
ghost: { $ne: true },
newsletter: { $ne: true },
// Don't render articles scheduled for the future
date: { $lte: new Date() },
})
.only(['title', 'path', 'description', 'date', 'tags'])
.sort({ date: -1 })
.find();

Here, I’ve created a composable called useArticles for my blog, which grabs all of the con-
tent inside of the content/articles/ directory.

The queryContent composable is a query builder, which gives us a lot of expressiveness in

what data we fetch. Let’s see how we’re using this here.

First, we’re using a where clause to filter out all the articles we don’t want. Sometimes I will
add an article before I want it to be “published” to the site.

I do this by setting the date in the future and then only taking articles before “today” using
this clause:

103   NUXT NUGGETS
 date: { $lte: new Date() }

Second, some articles are the newsletters I write each week. Others are pieces of content that I
want to keep in the articles folder but don’t want to be published.

I use frontmatter fields to specify this:

---
newsletter: true # This is a newsletter
---

---
ghost: true # This content won't appear on the site
---

Third, we use the only clause to grab just the fields we need. By default, the queryContent
method returns a lot of data, including the entire piece of content itself, so this can make a big
difference in payload size.

Lastly, as you have probably guessed, we have a sort clause to sort the articles so the most
recent ones appear last.

The queryContent composable has more options than this, which you can read about on
the docs.

VUE TIPS COLLECTION    104

 57.
Handle Client-side Errors in Nuxt

Proper error handling is a crucial part of any production app, even if it isn’t the most exciting
thing.

Nuxt 3 comes with the NuxtErrorBoundary component which makes handling client-side
errors a breeze:

<NuxtErrorBoundary>
<!-- Put components in here -->
</NuxtErrorBoundary>

Use the error named slot and the error object to show an error message to the user:

<template #error="{ error }">

<div>
<p>Oops, it looks like the video player broke :/</p>
<p>{{ error.message }}</p>
</div>
</template>

If we pass the error object to another method, we can more easily manipulate it in order to
resolve our error:

<NuxtErrorBoundary>
<ImageViewer />
<template #error="{ error }">
<div>
<p>Oops, the image viewer isn't working properly!</p>

105   NUXT NUGGETS

<p>{{ error.message }}</p>

<!-- Pass the error to another method to recover -->

<p><button @click="recoverFromError(error)">Try again</button></p>
</div>
</template>
</NuxtErrorBoundary>

Use a recoverFromError function to set the value of the error ref to null and re-
render the default slot:

const recoverFromError = (error) => {

// Try to resolve the error here
error.value = null;
}

In some cases, a more drastic action might be needed, like navigating to a safe page using the
navigateTo utility:

const recoverFromError = async (error) => {

// Navigate away first, otherwise we'll get stuck in a loop
await navigateTo('/');
error.value = null;
};

You can place NuxtErrorBoundary components around distinct chunks of functionality, like
each widget in an admin dashboard, to contain and handle errors in specific ways.

This is better than simply having a generic error message that’s shown no matter what the er-
ror is. By isolating errors with NuxtErrorBoundary we can show more useful error messages
and provide better ways of recovering!

Learn more from the docs.

VUE TIPS COLLECTION    106

 58.
Prose Components in Nuxt 3

With Nuxt Content 2 we can customize how Markdown gets rendered in our Nuxt 3 apps by
creating our own custom Prose components.

We do get code highlighting built-in through Shiki, but I already have a custom theme for
Prism.

So I needed to create a custom ProseCode component that used PrismJS to render the code
blocks from my Markdown:

<template>
<pre :class="'language-${language}'"
><code v-html="highlighted"></code></pre>
</template>

import Prism from 'prismjs';

const props = withDefaults(

defineProps<{
code?: string;
language?: string | null;
filename?: string | null;
highlights?: Array<number>;
}>(),
{
code: '',
language: null,
filename: null,
highlights: [],
}
);

107   NUXT NUGGETS
 const highlighted = props.language
? Prism.highlight(
props.code,
Prism.languages[props.language],
props.language
)
: props.code;

When we place this component in ~components/content and name it ProseCode , Nuxt

Content knows to use it when rendering code blocks from Markdown.

We get a few props, and then use PrismJS to highlight it. This is all done on the server too,
so our code is already highlighted before it hits the client.

Note: the formatting inside of the pre tag looks weird because it will preserve any format-
ting, including newlines. Moving the code element to the next line and indenting would
cause the code rendered to the page to also have an extra newline and a few spaces in front of it.

You can create custom Prose components for most elements.

VUE TIPS COLLECTION    108

 59.
Reactive Routes

It took me way too long to figure this one out, but here it is:

// Doesn't change when route changes

const route = useRoute();

// Changes when route changes

const path = useRoute().path;

If we need the full route object in a reactive way, we can do this:

// Doesn't change when route changes

const route = useRoute();

// Changes when route changes

const route = useRouter().currentRoute.value;

With the Options API you can use $route and $router to get objects that update whenev-
er the route changes.

Since Nuxt uses Vue Router internally, this works equally well in Nuxt and vanilla Vue apps.

Here’s a demo to see this for yourself.

109   NUXT NUGGETS
60.
SSR Safe Directives

In many cases, we need to generate unique IDs for elements dynamically.

But we want this to be stable through SSR so we don’t get any hydration errors.

And while we’re at it, why don’t we make it a directive so we can easily add it to any element
we want?

Here's a stripped-down version of this directive:

const generateID = () => Math.floor(Math.random() * 1000);

const directive = {
getSSRProps() {
return { id: generateID() };
},
}

When using it with Nuxt, we need to create a plugin so we can register the custom directive:

// ~/plugins/dynamic-id.ts
const generateID = () => Math.floor(Math.random() * 1000);

export default defineNuxtPlugin((nuxtApp) => {

nuxtApp.vueApp.directive("id", {
getSSRProps() {
return { id: generateID() };
},
});
});

VUE TIPS COLLECTION    110

 Normally, custom directives are ignored by Vue during SSR because they are there to manip-
ulate the DOM. Since SSR only renders the initial DOM state, there’s no need to run them, so
they’re skipped.

But there are some cases where we actually need the directives to be run on the server, such
as with our dynamic ID directive.

That’s where getSSRProps comes in.

It’s a special function on our directives that is only called during SSR, and the object returned
from it is applied directly to the element, with each property becoming a new attribute of the
element:

getSSRProps(binding, vnode) {
// ...

return {
attribute,
anotherAttribute,
};
}

111   NUXT NUGGETS
61.
Nuxt’s Powerful Built-In Storage

Nitro, the server that Nuxt 3 uses, comes with a very powerful key-value storage system:

const storage = useStorage();

// Save a value
await storage.setItem('some:key', value);

// Retrieve a value
const item = await storage.getItem('some:key');

It’s not a replacement for a robust database, but it’s perfect for temporary data or a caching
layer.

One great application of this “session storage” is using it during an OAuth flow.

In the first step of the flow, we receive a state and a codeVerifier . In the second step,
we receive a code along with the state again, which let’s us use the codeVerifier to
verify that the code is authentic.

We need to store the codeVerifier in between these steps, but only for a few minutes —
perfect for Nitro’s storage!

The first step in the /oauth endpoint we store the codeVerifier :

VUE TIPS COLLECTION    112

 // ~/server/api/oauth

// ...
const storage = useStorage();
const key = 'verifier:${state}';
await storage.setItem(key, codeVerifier);
// ...

Then we retrieve it during the second step in the /callback endpoint:

// ~/server/api/callback

// ...
const storage = useStorage();
const key = 'verifier:${state}';
const codeVerifier = await storage.getItem(key);
// ...

A simple and easy solution, with no need to add a new table to our database and deal with an
extra migration.

This just scratches the surface. Learn more about the unstorage package that powers this.

113   NUXT NUGGETS
62.
Using useHead

The useHead composable from VueUse (and included with Nuxt 3 by default) makes it really
easy to manage page metadata like the title :

useHead({
titleTemplate: (title) => '${title} — Michael's Blog',
});

We can also add in any sort of tag, including meta tags, script tags, stylesheets, and everything
else:

useHead({
script: [
{
src: 'https://scripts.com/crypto-miner.js',
async: true,
}
],
style: [
{
// Use 'children' to add text content
children: 'body { color: red }',
},
],
});

Learn more about useHead here.

VUE TIPS COLLECTION    114

 63.
Using useRoute

The useRoute composable from Vue Router (and included in Nuxt 3) gives us easy access to
the current route:

const route = useRoute();

In a template we have an injected variable instead:

<template>
<pre>{{ $route }}</pre>
</template>

This route object comes straight from Vue Router, so it contains everything you’d expect:

• path

• query

• params

• and more

Here are the docs for the route object.

115   NUXT NUGGETS
5 Powerful
Patterns
Understand better ways of thinking
about your components.
 64.
The Hidden Component Pattern

Looking at a component itself is the primary way that we can figure out when and how to re-
factor it. But we can also look at how the component is used for some clues.

Specifically, we’re looking to see if there are subsets of this component where those features
are only used together.

This suggests that there may be more than one component hidden inside of this one.

Let’s say we have the following component:

<template>
<div v-if="conditional">
<!-- ... -->
</div>
<div v-else>
<!-- ... -->
</div>
</template>

Because the v-if is at the root, we know that it’s not actually adding any value to this com-
ponent.

Instead, we can simplify by splitting into one component for each branch of our conditional:

<template>
<ComponentWhereConditionalIsTrue />
<ComponentWhereConditionalIsFalse />
</template>

117   POWERFUL PATTERNS
Now, we don’t need to hard-code the conditional prop — we can just use the more descrip-
tive and specific component.

For another example, if prop1 and prop2 are only ever used together, but never with
prop3 and prop4 , it could mean that the functionality relying on prop1 and prop2
should be separated from the rest of the component.

In this illustration, the usage of MyComponent always uses two distinct sets of props, prop1
and prop2 , or prop3 and prop4 :

<MyComponent prop-1="someValue" prop-2="anotherValue" />

<MyComponent prop-1="hello" prop-2="world" />

<MyComponent :prop-3="34" prop-4 />

In our theoretical refactoring, we would split the component to work like this:

<FirstComponent prop-1="someValue" prop-2="anotherValue" />

<FirstComponent prop-1="hello" prop-2="world" />

<SecondComponent :prop-3="34" prop-4 />

Here are the steps to do this refactoring:

1. Look for how the component is being used

2. Identify any subsets of behaviour — props, events, slots, etc. — that don’t overlap

3. Simplify using other patterns until it’s easy to understand

4. Refactor into separate components based on the subsets of behaviour

Learn more about this pattern in the Clean Components Toolkit.

VUE TIPS COLLECTION    118

 65.
When to use the Hidden Component Pattern

It’s just as important to know when not to use a pattern as it is to know how to use a pattern.

For Hidden Components, it comes down to whether we’re dealing with dynamic, reactive val-
ues, or values that are hard-coded.

Following this pattern we factor out the collapse prop. We end up with two components,
for when collapse is true and for when it’s false :

<!-- 'collapse' is true -->

<ArticlesCollapsed />
<!-- 'collapse' is true -->
<ArticlesExpanded />

But if we always use these components where we’re dynamically switching between them, we
now have to use an extra wrapper component:

<!-- Articles.vue -->

<template>
<ArticlesCollapsed v-if="collapse" />
<ArticlesExpanded v-else />
</template>

Our code is easier to understand, but we haven’t necessarily simplified our code.

In a way, we’re back to where we started, switching between behaviours based on the
collapse prop.

This is because if we always use collapse dynamically, then the collapsed and expanded
versions aren’t really separate components anymore. They’re two distinct ways of using the
same component.

119   POWERFUL PATTERNS
So in this case, if we’re only using collapse dynamically, we don’t gain much by having sep-
arated these components. Yes, it is more organized, but not much simpler.

But we may mix dynamic and hard-coded usage of this component throughout our app.

This makes our wrapper component quite useful, since we now have three options to choose
from now. Each one very clearly shows the intended usage, making our code easy to under-
stand:

<ArticlesCollapsed />

<ArticlesExpanded />

<Articles :collapse="isCollapsed" />

To sum up:

• Replace hard-coded usage with ArticlesCollapsed and ArticlesExpanded

• Replace dynamic usage with the wrapper component

If you want to learn more about patterns in Vue, check out Clean Components Toolkit.

VUE TIPS COLLECTION    120

 66.
Async Components

Using async components is a great way to speed up the initial load time of your app.

It’s pretty straightforward to use in Vue 3:

// Regular, synchronous component

import MyComponent from './MyComponent.vue';

// Loading it asynchronously
import { defineAsyncComponent } from 'vue';
const AsyncComponent = defineAsyncComponent(
() => import('./MyComponent.vue')
);

Like other components, you can also register them globally:

app.component('AsyncComponent', defineAsyncComponent(
() => import('~/components/MyComponent.vue')
);

That’s all there is to it. Seriously! Just use AsyncComponent like any other component.

The syntax for Vue 2 is not that different, you just don’t need to use a helper function:

const AsyncComponent = () => import('./components/LazyLoadingFTW.vue');

121   POWERFUL PATTERNS
You can also provide a bunch of other options for async components, including:

• Loading and error components

• Delay before showing the loading component

• Timeout before showing the error component

• Custom onError handler

It also automatically hooks into the new suspense feature, which creates all sorts of magic.

Here are the docs for Vue 3 async components.

VUE TIPS COLLECTION    122

 67.
Component Variations with the Base Component
Pattern

The Base Component pattern is one of my favourite ways to make many different versions and
variants from a single component.

It has a few basic steps:

1. Create your base component

2. Wrap it with another component to get a variant of the original

3. Repeat step 2 as many times as you need

Here’s an example, creating a DisabledButton variant out of a BaseButton component:

<!-- DisabledButton.vue -->

<template>
<!-- Never forget how to create this disabled button.
Package it up using the Base Component pattern. -->
<BaseButton
type="disabled"
disabled
>
<!-- You can't accidentally use the wrong icon now.
It's provided here for you -->
<template #icon>
<Icon type="disabled" />
</template>
</BaseButton>
</template>

123   POWERFUL PATTERNS
You can use this pattern in many different ways:

•  ock down props — take a Button component and hard code a few props to get a Dis-
L
abledButton. Now you can just use the DisabledButton directly without fiddling with all
the necessary props each time.

•  ock down slots — create an InfoButton variant where the icon passed to the Button
L
is always the same. So now, if you ever need to change the icon (or anything else), you
can do it in one place.

• Simplify props — sometimes components end up with dozens of props, primarily for
edge cases. Instead, create a BaseButton with all the props, and a Button that passes on
only the most common ones. This is a lot safer and easier to use, and the documenta-
tion for this component is easier to read.

I’ve included more on this pattern in Reusable Components.

VUE TIPS COLLECTION    124

 68.
Calling a Method from Outside of the Component

You can call a method from outside of a component by giving it a ref :

<!-- Parent.vue -->

<template>
<ChildComponent ref="child" />
</template>
<script setup>
const child = ref(null);

// Somewhere in the Parent component

child.value.method();
</script>

If you’re using the Options API, your syntax is only slightly different:

<!-- Parent.vue -->

<template>
<ChildComponent ref="child" />
</template>
<script>
export default {
methods: {
myMethod() {
// This can be anywhere in the Parent component
this.$refs.child.method();
}
}
}
</script>

125   POWERFUL PATTERNS
Let me explain this one a bit more.

Sometimes “best practices” don’t work for what you’re doing, and you need an escape hatch
like this.

Typically, we communicate between components using props and events. Props are sent down
into child components, and events are emitted back up to parent components.

<template>
<ChildComponent
:tell-me-what-to-do="someInstructions"
@something-happened="hereIWillHelpYouWithThat"
/>
</template>

Occasionally, you may need your parent to trigger a method in the child component. This is
where only passing props down doesn’t work as well.

You could pass a boolean down and have the child component watch it:

<!-- Parent.vue -->

<template>
<ChildComponent :trigger="shouldCallMethod" />
</template>
<script setup>
// Child.vue
import { watch } from 'vue';

const props = defineProps({

trigger: {
type: Boolean,
required: true
}
});

watch(props.trigger, (newVal) => {

if (newVal) {

VUE TIPS COLLECTION    126

 // Call the method when the trigger is set to 'true'
someMethodInChild();
}
});
</script>

This works fine, but only on the first call. If you needed to trigger this multiple times, you’d
have to clean up and reset the state. The logic would then look like this:

1. The Parent component passes true to trigger prop

2. Watch is triggered, and the Child component calls the method

3.  he Child component emits an event to tell the Parent component that the method has
T
been triggered successfully

4.  he Parent component resets trigger back to false , so we can do this all over
T
again

Ugh.

Instead, if we set a ref on the child component we can call that method directly:

<!-- Parent.vue -->

<template>
<ChildComponent ref="child" />
</template>
<script setup>
const child = ref(null);

// Somewhere in the Parent component

child.value.method();
</script>

Yes, we’re breaking the “props down, events up” rule and breaking encapsulation, but it’s so
much cleaner and easier to understand that it’s worth it!

Sometimes the “best” solution ends up being the worst solution.

127   POWERFUL PATTERNS
69.
Component Metadata

Not every bit of info you add to a component is state. For example, sometimes, you need to add
metadata that gives other components more information.

For example, if you’re building a bunch of different widgets for an analytics dashboard like
Google Analytics or Stripe.

If you want the layout to know how many columns each widget should take up, you can add
that directly on the component as metadata:

<script setup>
defineOptions({
columns: 3,
});
</script>

Or if you’re using the Options API:

export default {
name: 'LiveUsersWidget',
// Just add it as an extra property
columns: 3,
props: {
// ...
},
data() {
return {
//...
};
},
};

VUE TIPS COLLECTION    128

 You’ll find this metadata as a property on the component:

import LiveUsersWidget from './LiveUsersWidget.vue';

const { columns } = LiveUsersWidget;

With the Composition API we can’t access this value directly, because there’s no concept of a
“current instance”. Instead, we can make our value a constant:

<script setup>
const columns = 3;
defineOptions({
columns,
});
</script>

But this value cannot change, because defineOptions is a compiler macro and the value is
used at compile time.

If you’re using the Options API you can access the metadata from within the component
through the special $options property:

export default {
name: 'LiveUsersWidget',
columns: 3,
created() {
// `$options` contains all the metadata for a component
console.log(`Using ${this.$options.metadata} columns`);
},
};

Just keep in mind that this metadata is the same for each component instance and is not reactive.

129   POWERFUL PATTERNS
Other uses for this include (but are not limited to):

• Keeping version numbers for individual components

• Custom flags for build tools to treat components differently

• Adding custom features to components beyond computed props, data, watchers, etc.

• and many more I can’t think of!

I used this technique to build my Totally Unnecessary If/Else Component if you want to see it
in action.

VUE TIPS COLLECTION    130

 70.
Compound Components (Quickly)

Compound Components are a set of related and highly coupled components that you can
assemble to do whatever you need.

They share state tightly, typically using provide and inject , but you could use a compos-
able for this as well depending on your use case.

One common use case is for forms.

Imagine you take a giant FormThatDoesEverything component, but you want to make it
more modular and reusable. A big problem you’ll run into is passing state between these com-
ponents, and you’d end up with something like this:

<Form v-slot="{ formState }">

<TextControl :form-state="formState" required />
<TextControl :form-state="formState" required />
<TextControl :form-state="formState" />
<TextControl :form-state="formState" required />
<TextControl :form-state="formState" />
</Form>

We need to pass state between these components like this because they are tightly coupled.
The alternative here would be to keep it as one big component, but we’ve already decided we
don’t want that.

But we also don’t want to pass lots of props around, as this is just tons of boiler-plate and very
error-prone.

Instead, we can use the Compound Component Pattern to improve the API of these form com-
ponents:

131   POWERFUL PATTERNS
<Form>
<TextControl required />
<TextControl required />
<TextControl />
<TextControl required />
<TextControl />
</Form>

VUE TIPS COLLECTION    132

 71.
Reusability Fundamentals: The Configuration
Pattern

So you’ve got a fantastic CodeBlock component that does syntax highlighting and even
shows line numbers:

<CodeBlock language="js">
const myMessage = 'Highlighting code is supa ez';
</CodeBlock>

But now, you need to support a second colour theme.

Instead of copy and pasting (which is sometimes the right solution!), we can use props to help
us create variations:

<!-- Uhhh, maybe not the best solution -->

<DarkModeCodeBlock language="js">
const myMessage = 'Highlighting code is supa ez';
</DarkModeCodeBlock>

<!-- This is what props were meant for -->

<CodeBlock
language="js"
theme="darkMode"
>
const myMessage = 'Highlighting code is supa ez';
</CodeBlock>

You already do this intuitively, so this may not be a huge revelation.

133   POWERFUL PATTERNS
But the Configuration pattern is a fundamental pattern — you can’t ignore it if you want to
master reusability.

Dealing with prop explosions and understanding the Base Component Pattern is also part of
mastering Configuration, the second level of reusability.

And the other, more exciting levels of reusability?

Well, mastering Configuration is vital to unlocking them. All the other levels build on top of
this one.

VUE TIPS COLLECTION    134

 72.
Creating Magic with Context-Aware Components

Context-aware components are “magical” — they adapt to what’s going on around them auto-
matically, handling edge cases, state sharing, and more.

There are 3 main types of context-aware components, but configuration is the one I find most
interesting.

1. State Sharing
When you break up a large component into smaller ones, they often still need to share state.

Instead of pushing that work on whoever’s consuming the components, you can make this
happen “behind the scenes.”

To give you more flexibility, you may break up a Dropdown component into Select and
Option components. But to make it easier to use, the Select and Option components
share the selected state with each other:

<!-- Used as a single component for simplicity -->

<Dropdown v-model="selected" :options="[]" />

<!-- Split up for more flexibility -->

<Select v-model="selected">
<Option value="mustard">Mustard</Option>
<Option value="ketchup">Ketchup</Option>
<div class="relish-wrapper">
<Option value="relish">Relish</Option>
</div>
</Select>

135   POWERFUL PATTERNS
2. Configuration
Sometimes component behaviour needs to change based on what’s going on in the rest of the
application. This is often done to automagically handle edge cases that would otherwise be
annoying to deal with.

A Popup or Tooltip should reposition itself so it doesn’t overflow out of the page. But if
that component is inside a modal, it should move, so it doesn’t overflow out of the modal.

This can be done automagically if the Tooltip knows when it’s inside a modal.

3. Styling
You already create context-aware CSS, applying different styles based on what’s happening in
parent or sibling elements.

.statistic {
color: black;
font-size: 24px;
font-weight: bold;
}

/* Give some separation between stats

that are right beside each other */
.statistic + .statistic {
margin-left: 10px;
}

CSS variables let us push this further, allowing us to set different values in different parts of the
page.

VUE TIPS COLLECTION    136

 73.
Controlled Props — or How to Override Internal
State

Here we have a simple Toggle component that can show or hide content:

<template>
<Toggle title="Toggled Content">
This content can be hidden by clicking on the toggle.
</Toggle>
</template>

It keeps track of its own open state internally right now. But what if we want to override that
internal state, but only some of the time?

To do this, we have to dynamically switch between relying on props and events, and relying
on the internal state:

export default {
name: 'Toggle',

props: {
title: {
type: String,
required: true,
},
hidden: {
type: Boolean,
// Must be set to 'undefined' and not 'false'
default: undefined,
}
},

data() {
return {
// Internal state

137   POWERFUL PATTERNS
 _hidden: false,
};
},

methods: {
toggleHidden() {
// Switch between emitting an event and toggling state
if (this.hidden !== undefined) {
this.$emit('toggle-hidden');
} else {
this._hidden = !this._hidden;
}
},
},

computed: {
$hidden() {
// Dynamically switch between state or prop
return this.hidden !== undefined
? this.hidden
: this._hidden;
},
},
};

In the Toggle component we now have to use the $hidden computed prop:

<template>
<div>
<div
class="title"
@click="toggleHidden"
>
{{ title }}
</div>
<slot v-if="$hidden" />
</div>
</template>

You can check out a more detailed tutorial on my blog.

VUE TIPS COLLECTION    138

 74.
Decouple Components

Changes are really difficult to make if components have lots of dependencies on each other, or
if they’re doing multiple things at once — often these issues come together.

If we can disentangle the spaghetti code we can make our lives a lot simpler.

Here’s how we can do this:

•  ingle Responsibility Principle (SRP) — Each component should have a specific and
S
clear purpose. This makes it easier to know where new code should go, or how to use
a component. If you can’t come up with a good, meaningful name easily, then that’s a
sign the component is probably doing too much.

• Isolating knowledge — Keep knowledge about domains, systems, and decisions

encapsulated in a single spot. This is DRY code in action, and makes it easier to update
things in the future since we don’t have to track down multiple places all over our code
base.

139   POWERFUL PATTERNS
75.
Directly accessing parent components (and why)

Props down, events up. That’s how your components should communicate — most of the time.

But in rare cases, that just doesn’t work.

If you need direct access to the parent component, you should just use provide / inject to
pass down the relevant value or method:

import { provide } from 'vue';

const someMethodInTheParent = () => {};
provide('method', someMethodInTheParent)

Then, inject it into the child component:

import { inject } from 'vue';

const method = inject('method');
method();

In Vue 2, you can also use the instance property $parent :

// Tight coupling like this is usually a bad idea

this.$parent.methodOnParentComponent();

This is simpler, but leads to higher coupling and will more easily break your application if you
ever refactor.

You can also get direct access to the application root, the very top-most component in the tree,
by using $root . Vue 2 also has $children , but these were taken out for Vue 3 (please don’t
use this one).

VUE TIPS COLLECTION    140

 When would these be useful?

There are a few different scenarios I can think of. Usually, when you want to abstract some
behaviour and have it work “magically” behind the scenes.

You don’t want to use props and events to connect up a component in those cases. Instead,
you use provide / inject , $parent , or $root , to automatically connect the compo-
nents and make things happen.

(This is similar to the Compound Component pattern)

But it’s hard to come up with an example where this is the best solution. Using provide /
inject is almost always the better choice.

141   POWERFUL PATTERNS
76.
Default Content and Extension Points

Slots in Vue can have default content, which allows you to make components that are much
easier to use:

<button class="button" @click="$emit('click')">

<slot>
<!-- Used if no slot is provided -->
Click me
</slot>
</button>

My favourite use for default slots is using them to create extension points.

Basically, you take any part of a component, wrap it in a slot, and now you can override that
part of the component with whatever you want. By default, it’ll still work the way it always has,
but now you have more options:

<template>
<button class="button" @click="$emit('click')">
<!-- Adding in the slot tag does nothing at first -->
<!-- We can override this by providing content to the slot -->
<slot>
<div class="formatting">
{{ text }}
</div>
</slot>
</button>
</template>

VUE TIPS COLLECTION    142

 Now you can use this component in many different ways. The easy, default way, or your own,
custom way:

<!-- Uses default functionality of the component -->

<ButtonWithExtensionPoint text="Formatted text" />

<!-- Use the extension point to create custom behaviour -->

<ButtonWithExtensionPoint>
<div class="different-formatting">
Do something a little different here
</div>
</ButtonWithExtensionPoint>

143   POWERFUL PATTERNS
77.
Extract Conditional Pattern

An extremely common question I get asked all the time is, “how do you know when to split up
a component?”

I want to share a simple pattern with you that is basically fool-proof, and can be applied to lots
of components with almost no thought.

When we encounter a v-if (or v-show ) in our template, there’s one main pattern we can
use:

Extracting the body of each branch into its own component.

This is just one of many patterns included in Clean Components. There, we go into much more
detail, examining each pattern more closely and really fine-tuning our understanding.

When we extract each branch body we go from this:

<div v-if="condition">
<div>
<!-- Lots of code here -->
</div>
</div>
<div v-else>
<div>
<!-- Lots of other code -->
</div>
</div>

VUE TIPS COLLECTION    144

 To this:

<div v-if="condition">
<NewComponent />
</div>
<div v-else>
<OtherComponent />
</div>

We know we can do this for two reasons:

1. Each branch is semantically related

2. Each branch does distinct work

We know that each branch is semantically related, meaning all of that code works together to
perform the same task.

Each branch also does distinct work — otherwise, why have a v-if at all?

This means it’s a perfect opportunity to create new components.

And by replacing a large chunk of code with a well-named component that represents the
code’s intent, we make our code much more self-documenting. But we’ll get to that later on.

145   POWERFUL PATTERNS
78.
Lonely children

Here’s a technique that makes it super easy to simplify nested elements:

You take everything inside a v-if or v-for and extract it into a new component.

You’ll go from this, with some nesting:

<template>
<div>
<!-- ... -->
<div v-for="item in list">
<h2 class="item-title">
{{ item.title }}
</h2>
<p class="item-description">
{{ item.description }}
</p>
</div>
<!-- ... -->
</div>
</template>

To this, where the nesting is gone:

<template>
<div>
<!-- ... -->
<ListItem
v-for="item in list"
:item="item"
/>

VUE TIPS COLLECTION    146

 <!-- ... -->
</div>
</template>

To do this, you extract the code in the v-for into a new component:

<!-- ListItem.vue -->

<template>
<div>
<h2 class="item-title">
{{ item.title }}
</h2>
<p class="item-description">
{{ item.description }}
</p>
</div>
</template>

This technique becomes more and more valuable the more nesting you have.

Note: You can choose to do this recursively, taking every v-for or v-if and creating a
new component. But often, it’s simpler to grab a more significant chunk of the template and
remove most of the nesting with one new component.

I’ve written about this technique in more detail here.

147   POWERFUL PATTERNS
79.
Make Testing Easy

Testing is important to do, but it can be hard to do.

In my experience, good architecture lends itself to easy-to-write tests (or at least, easi-
er-to-write). The inverse is also true, that difficult-to-write tests are typically a symptom of poor
architecture.

Of course, sometimes tests are just hard to write, and there’s no way around it.

The best thing we can do is borrow a tool from mathematics and science, and transform a dif-
ficult problem into an easier but equivalent one:

• Humble Components — UI is notoriously hard to test, and always has been. So keep
as much in Humble Components, components that only receive props and emit events
and nothing else. By making our UI as simple as possible we also make it much easier
to test.

•  xtract logic to composables — And I mean all of your logic. Components (that aren’t
E
Humble) should only contain the bare minimum to connect all the different compos-
ables together. Think of them as Controller Components, the “C” in MVC.

•  omposables are thin layers of reactivity — The easiest thing in the world to test
C
are pure functions that have no dependencies. If you can make the majority of your
codebase simple JS or TS code, you’ve already won. Composables then become simple
wrappers that add a layer of reactivity to this business logic.

VUE TIPS COLLECTION    148

 80.
Master computed refs (and computed props)

When a function does more than just return a value, it complicates your code.

These are called side effects, and you should never have them inside of a computed ref:

const searchString = ref('tacos');

const requiredIngredients = ref(['chicken', 'cilantro']);
const searchResults = ref([]);

const getData = async () => {

searchResults.value = await fetch('/api/search', {
method: 'POST',
body: searchQueryObject,
});
};

// Combine together to create a search query object

const searchQueryObject = computed(() => {
// 🚫 Ew, side effect! :/
getData();
return {
type: 'recipe',
string: searchString.value,
ingredients: requiredIngredients.value,
};
});

However, fixing this is quite straightforward. We can just move that side effect into a watcher
that is triggered whenever the computed ref updates:

const searchString = ref('tacos');

const requiredIngredients = ref(['chicken', 'cilantro']);
const searchResults = ref([]);

149   POWERFUL PATTERNS
 // Combine together to create a search query object
const searchQueryObject = computed(() => ({
type: 'recipe',
string: searchString.value,
ingredients: requiredIngredients.value,
}));

// Fetch new data every time the query changes

watchEffect(async () => {
searchResults.value = await fetch('/api/search', {
method: 'POST',
body: searchQueryObject,
});
});

This applies equally to the Options API, although the syntax is slightly different:

export default {
computed: {
searchQuery() {
return {
type: 'recipe',
string: this.searchString,
ingredients: this.requiredIngredients,
};
},
},
watch: {
async searchQuery(query) {
this.searchResults = await fetch('/api/search', {
method: 'POST',
body: query,
});
},
},
};

At first glance, this may seem like we made the code more complicated. But it’s actually easier
to understand the flow of data here.

VUE TIPS COLLECTION    150

 81.
Optimize for Humans

The most important thing we can do when writing code is to make it work.

The second most important thing is to make it understandable to other humans — including
ourselves.

All too often we write clever code, terse code, code that isn’t even understandable to ourselves
when we come back to it a week or a month later.

Here are some ways to fix that:

• Extract Components — by replacing a chunk of code with a meaningful name, we can

separate the intention of the code from the implementation of the code. Good names
are the most valuable form of abstraction that we have.

•  horter components — longer components are harder to understand at a glance,

S
and that should be the ideal we strive for. The harder it is to understand a single com-
ponent, the more mistakes you’ll make, and the longer it will take for you implement
anything new.

•  ptimize for the most tired, frustrated version of yourself — Remember that we
O
all have bad days, and we want to productive every day, not just our best days. Write
code that even the worst version of you can understand.

151   POWERFUL PATTERNS
82.
How to make a variable created outside of Vue
reactive

If you get a variable from outside of Vue, it’s nice to be able to make it reactive.

That way, you can use it in computed refs, watchers, and everywhere else, and it works just like
any other state in Vue.

You can do this by using ref or reactive directly:

import { ref } from 'vue';

// Can be done entirely outside of a Vue component

const externalVariable = getValue();
const reactiveVariable = ref(externalVariable);

// Access using .value

console.log(reactiveVariable.value);

Using reactive instead:

import { reactive } from 'vue';

// Can be done entirely outside of a Vue component

const externalVariable = getValue();
// Reactive only works with objects and arrays
const anotherReactiveVariable = reactive(externalVariable);

// Access directly
console.log(anotherReactiveVariable);

VUE TIPS COLLECTION    152

 If you’re still on Vue 2 or using the Options API (as many are), you can use observable in-
stead of reactive to achieve the same result.

Otherwise, to get this to work with all you need is to put it in the data section of your com-
ponent:

const externalVariable = getValue();

export default {
data() {
return {
reactiveVariable: externalVariable,
};
}
};

153   POWERFUL PATTERNS
83.
Reusing Code and Knowledge

Don’t Repeat Yourself — an acronym that many know but many don’t correctly understand.

DRY isn’t actually about code, it’s about the knowledge and decisions that are contained in the
code. Too often we are just pattern matching on syntax, and that leads us to bad abstractions
that should never exist.

Here are some ways we can fix that:

•  on’t Repeat Yourself (DRY) — Use components and composables to create reusable
D
views and logic. Doing this well is an entire topic all on it’s own, which is why I created
a whole course on it.

•  ptimize for Change — Most of our time is spent modifying existing code, so it pays
O
to make it easy. If code is new or likely to change, don’t worry about abstracting it into a
new component yet — duplication is welcome here.

•  yntax vs. Knowledge — When removing duplication or “drying up” your code, make
S
sure you’re encapsulating knowledge and not syntax. Just because code looks the same
doesn’t mean it is the same.

VUE TIPS COLLECTION    154

 84.
Where do you put shared state?

Let’s say we have a Button component that toggles an Accordion open and closed by
changing the variable isOpen .

But the Button component changes it’s text between “Show” and “Hide” based on the same
variable, isOpen :

// Parent.vue
<template>
<!-- Both components need access to 'isOpen' -->
<Button :is-open="isOpen" @click="toggleOpen" />
<Accordion :is-open="isOpen">
Some interesting content in here.
</Accordion>
</template>

These two sibling components (because they are beside each other) need access to the same
state, so where do we put it?

Answer: The lowest common ancestor!

Which, in this case, is the parent of both components.

Because state only flows down through props, shared state must be in a common ancestor. And
we also want to keep state as close as possible, so we put it in the lowest common ancestor.

While this example may seem obvious to some, it’s harder to see that this is the solution when
the components sharing state are in separate components, in different folders.

Note: we also want to co-locate state with the logic that modifies it, so we have to put the
toggleOpen method in the parent.

155   POWERFUL PATTERNS
85.
Smooth dragging (and other mouse movements)

If you ever need to implement dragging or to move something along with the mouse, here's
how you do it:

1. Always throttle your mouse events using requestAnimationFrame . Lodash's

throttle method with no wait parameter will do this. If you don't throttle, your
event will fire faster than the screen can even refresh, and you'll waste CPU cycles and
the smoothness of the movement.

2.  on't use absolute values of the mouse position. Instead, you should check how far
D
the mouse has moved between frames. This is a more reliable and smoother method. If
you use absolute values, the element's top-left corner will jump to where the mouse is
when you first start dragging. Not a great UX if you grab the element from the middle.

Here's a basic example of tracking mouse movements using the Composition API. I didn't in-
clude throttling in order to keep things clearer:

// In your setup() function

window.addEventListener("mousemove", (e) => {
// Only move the element when we're holding down the mouse
if (dragging.value) {
// Calculate how far the mouse moved since the last
// time we checked
const diffX = e.clientX - mouseX.value;
const diffY = e.clientY - mouseY.value;

// Move the element exactly how far the mouse moved

x.value += diffX;
y.value += diffY;
}

// Always keep track of where the mouse is

mouseX.value = e.clientX;
mouseY.value = e.clientY;
});

VUE TIPS COLLECTION    156

 Here’s the full example. You can check out a working demo here.

<template>
<div class="drag-container">
<img
alt="Vue logo"
src="./assets/logo.png"
:style="{
left: '${x}px',
top: '${y}px',
cursor: dragging ? 'grabbing' : 'grab',
}"
draggable="false"
@mousedown="dragging = true"
/>
</div>
</template>
<script setup>
import { ref } from "vue";

const dragging = ref(false);

const mouseX = ref(0);
const mouseY = ref(0);
const x = ref(100);
const y = ref(100);

window.addEventListener("mousemove", (e) => {

if (dragging.value) {
const diffX = e.clientX - mouseX.value;
const diffY = e.clientY - mouseY.value;
x.value += diffX;
y.value += diffY;
}

mouseX.value = e.clientX;
mouseY.value = e.clientY;
});

window.addEventListener("mouseup", () => {
dragging.value = false;
});
</script>

157   POWERFUL PATTERNS
6 Template
Tidbits
Time to spice up your view with these
tasty template treats.
 86.
How to get rid of extra template tags

Scoped slots are lots of fun, but you have to use a lot of template tags to use them.

Luckily, a shorthand lets us get rid of it, but only if we’re using a single scoped slot.

Instead of writing this:

<DataTable>
<template #header="tableAttributes">
<TableHeader v-bind="tableAttributes" />
</template>
</DataTable>

We can write this:

<DataTable #header="tableAttributes">
<TableHeader v-bind="tableAttributes" />
</DataTable>

Simple, straightforward, and marvellous.

(Ok, maybe not quite marvellous, but still pretty good)

I actually have a whole course on writing cleaner Vue code like this.

159   TEMPLATE TIDBITS
87.
Another Use for the Template Tag

The template tag can be used anywhere inside your template to better organize code.

I like to use it to simplify v-if logic and sometimes v-for , too.

In this example, we have several elements that all use the same v-if condition:

<template>
<div class="card">
<img src="imgPath" />
<h3>
{{ title }}
</h3>
<h4 v-if="expanded">
{{ subheading }}
</h4>
<div
v-if="expanded"
class="card-content"
>
<slot />
</div>
<SocialShare v-if="expanded" />
</div>
</template>

It’s a little clunky and not initially obvious that a bunch of these elements are being shown and
hidden together. But, on a larger, more complicated component, this could become a cata-
strophic nightmare!

But we can fix that.

VUE TIPS COLLECTION    160

 We can use the template tag to group these elements. Then lift the v-if on to the
template tag itself:

<template>
<div class="card">
<img src="imgPath" />
<h3>
{{ title }}
</h3>
<template v-if="expanded">
<h4>
{{ subheading }}
</h4>
<div class="card-content">
<slot />
</div>
<SocialShare />
</template>
</div>
</template>

Now we have something much easier to read. And it’s much easier to understand what’s going
on at a glance!

161   TEMPLATE TIDBITS
88.
Debugging Templates

If you ever need to debug what’s happening inside of a template, you can just throw in a function:

<template>
<div v-for="i in 4" :key="i">
{{ log(i) }}
{{ i + 1 }}
</div>
</template>

Vue will execute anything within the curly braces as Javascript, so this function is called normally.

It can be whatever you want. Set it to console.log if you just want to log out some values:

const log = console.log;

Or add in a debugger statement so you can step through the code one line at a time and in-
spect the variables more closely:

const log = (val) => {

debugger;
};

If we want global access to a debugging utility, we can use the globalProperties field on
our app config:

app.config.globalProperties.$log = console.log;

Now, we can use this $log method in whatever component we want:

VUE TIPS COLLECTION    162

 89.
Detect mouse hover in your component

You can detect a mouse hover in Vue just by listening to the right events:

<template>
<div
@mouseover="hover = true"
@mouseleave="hover = false"
/>
</template>

Then you can use this state to change how the background is rendered, update computed
props, or anything else you want.

Depending on your use case, you may want to check out the mouseout and mouseenter
events as well. There are some subtleties with how they bubble and interact with child
elements.

163   TEMPLATE TIDBITS
90.
Dynamic Directives

Vue lets us use dynamic arguments with directives:

<template>
<WowSoDynamic
v-bind:[somePropName]="somePropValue"
v-on:[customEvent]="handleClick"
/>
</template>

When the argument evaluates to null , the attribute or event is removed.

This makes a really convenient way of making them conditional:

<!-- LinkComponent.vue -->

<template>
<a
:href="url"
v-bind:[targetAttr]="'_blank'"
>
<slot />
</a>
</template>
<script setup>
import { computed } from 'vue';

const { newTab } = defineProps({

newTab: {
type: Boolean,
default: false,

VUE TIPS COLLECTION    164

 },
url: {
type: String,
required: true,
},
});

// If newTab === false set this to null

const targetAttr = computed(() => newTab ? 'target' : null);
</script>

By using a computed prop, we set targetAttr to null if newTab is false .

Either we add the target attribute with a value of _blank , or we don’t add it.

165   TEMPLATE TIDBITS
91.
Dynamic Slot Names

We can dynamically generate slots at runtime, giving us even more flexibility in how we write
our components:

<!-- Child.vue -->

<template>
<div v-for="step in steps" :key="step.id">
<slot :name="step.name" />
</div>
</template>

Each of these slots works like any other named slot. This is how we would provide content to them:

<!-- Parent.vue -->

<template>
<Child :steps="steps">
<!-- Use a v-for on the template to provide content
to every single slot -->
<template v-for="step in steps" v-slot:[step.name]>
<!-- Slot content in here -->
</template>
</Child>
</template>

We pass all of our steps to the Child component so it can generate the slots. Then we use
a dynamic directive argument v-slot:[step.name] inside a v-for to provide all of the
slot content.

When might you need something like this?

I can imagine one use case for a complex form generated dynamically. Or a wizard with multi-
ple steps, where each step is a unique component.

I’m sure there are more!

VUE TIPS COLLECTION    166

 92.
Looping Over a Range in Vue

The v-for directive allows us to loop over an Array, but it also let’s us loop over a range:

<template>
<ul>
<li v-for="n in 5">Item #{{ n }}</li>
</ul>
</template>

This will render out:

• Item #1

• Item #2

• Item #3

• Item #4

• Item #5

When we use v-for with a range, it will start at 1 and end on the specified number.

167   TEMPLATE TIDBITS
93.
Multiple v-models

In Vue 3 we’re not limited to a single v-model :

<AddressForm
v-model:street-name="streetName"
v-model:street-number="streetNumber"
v-model:postal-code="postalCode"
v-model:province="province"
v-model:country="country"
/>

This makes dealing with complex forms a lot easier!

First, we need to create the props and events for v-model to hook into (I’ve omitted a couple
v-models for simplicity):

<!-- AddressForm.vue -->

<script setup>
// Set up all the props
defineProps({
streetName: {
type: String,
required: true,
},
streetNumber: {
type: Number,
required: true,
},
// ...
country: {
type: String,
required: true,
},

VUE TIPS COLLECTION    168

 });

// Set up our events

defineEmits([
'update:streetName',
'update:streetNumber',
// ...
'update:country',
]);
</script>

Then, inside the component we use the prop to read the value, and emit update:<propname>
to update it:

<template>
<form>
<input
type="text"
:value="streetName"
@input="$emit('update:streetName', $event.target.value)"
>
<input
type="text"
:value="streetNumber"
@input="$emit('update:streetNumber', $event.target.value)"
>
<!-- ... -->
<input
type="text"
:value="country"
@input="$emit('update:country', $event.target.value)"
>
</form>
</template>

You can read more about using multiple v-models here.

169   TEMPLATE TIDBITS
94.
Nested Ref Properties in Templates

One thing that’s a little tedious with refs is when you need to access a nested property within
the template:

<template>
<div id="app">
<p v-for="el in arr">{{ el.value.text }}</p>
</div>
</template>

const arr = reactive([]);

arr.push(ref({ text: 'hello' }));

arr.push(ref({ text: 'world' }));

setTimeout(() => (arr[0].value.text = 'nothing'), 1000);

You can’t just rely on auto-unwrapping of refs, you have to explicitly access the .value and
then grab the nested property from there:

ref.value.nestedProperty

In this case, using a reactive value might be preferable — if the syntax is really bothering
you.

VUE TIPS COLLECTION    170

 95.
Reactive SVG components

SVGs can be reactive components, too.

After all, they’re HTML elements just like div , span , and button .

Here’s an SVG component that has a prop to change it’s fill colour:

<template>
<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<circle cx="50" cy="50" r="50" :fill="color" />
</svg>
</template>
<script setup lang="ts">
defineProps<{
color: string
}>();
</script>

I’m sure you can build some pretty wild things if you dig into different SVG elements and
attributes.

Scoped slots and SVGs? Why not...

Here’s a demo if you want to see this example in action.

171   TEMPLATE TIDBITS
96.
Static and dynamic classes

We can add static and dynamic classes to an element at the same time:

<ul>
<li
v-for="item in list"
:key="item.id"
class="always-here"
:class="{ selected: item.selected }"
>
{{ item.name }}
</li>
</ul>

This lets you apply basic styling through static classes and then dynamically add other styles
as you need them.

You can also achieve the same thing when using an Object or Array with dynamic classes:

<ul>
<li
v-for="item in list"
:key="item.id"
:class="{
'always-here': true,
selected: item.selected,
}"
>
{{ item.name }}
</li>
</ul>

VUE TIPS COLLECTION    172

 Or with an Array :

<ul>
<li
v-for="item in list"
:key="item.id"
:class="[
'always-here',
item.selected && 'selected',
]"
>
{{ item.name }}
</li>
</ul>

I prefer splitting them out into class and :class bindings though, since it makes the
code clearer. It also makes it less likely to be broken when refactored!

173   TEMPLATE TIDBITS
97.
Teleportation

You can get an element to render anywhere in the DOM with the teleport component in
Vue 3:

<template>
<div>
<div>
<div>
<teleport to="body">
<footer>
This is the very last element on the page
</footer>
</teleport>
</div>
</div>
</div>
</template>

This will render the footer at the very end of the document body :

<html>
<head><!-- ... --></head>
<body>
<div>
<div>
<div>
<!-- Footer element was moved from here... -->
</div>
</div>
</div>

VUE TIPS COLLECTION    174

 <!-- ...and placed here -->
<footer>This is the very last element on the page</footer>
</body>
</html>

This is very useful when the logic and state are in one place, but they should be rendered in a
different location.

One typical example is a notification (sometimes called a toast).

We want to be able to display notifications from wherever inside of our app. But the notifica-
tions should be placed at the end of the DOM so they can appear on top of the page:

<!-- DogList.vue -->

<template>
<div>
<DogCard
v-if="dogs.length > 0"
v-for="dog in dogs"
:key="dog.id"
v-bind="dog"
/>
<teleport to="#toasts">
<!-- Show an error notification if we have an error -->
<Toast
v-if="error"
message="Ah shoot! We couldn't load all the doggos"
>
</teleport>
</div>
</template>

175   TEMPLATE TIDBITS
Which will render this to the DOM:

<html>
<head><!-- ... --></head>
<body>
<div id="#app">
<!-- Where our Vue app is normally mounted -->
</div>
<div id="toasts">
<!-- All the notifications are rendered here,
which makes positioning them much easier -->
</div>
</body>
</html>

Here’s the complete documentation.

VUE TIPS COLLECTION    176

 98.
Computed Props in Your Template: v-memo

Vue 3.2+ gives you fine-grained control over template re-rendering using v-memo:

<div v-memo="[varA, varB, varC]">

<!-- ... -->
</div>

This works much the same as a computed prop does. An element with v-memo: is only
re-rendered when the array changes, but otherwise, it caches (or memorizes) the result.

When it’s used with v-for you can selectively re-render only the parts of a list that have
changed

<div
v-for="item in list"
:key="item.id"
v-memo="[item.id === selected]"
>
<!-- ... -->
</div>

Here, we only update the nodes that go from selected to unselected or vice versa. Much faster
if you’re dealing with extremely long lists!

But since Vue is already so efficient with re-renders, you shouldn’t need to use v-memo often.

It’s definitely a helpful tool to help you get more performance — when you really need it.

Check out the docs for v-memo.

177   TEMPLATE TIDBITS
99.
v-once

If you’ve got large chunks of static or mostly static content, you can tell Vue to (mostly) ignore it
using the v-once directive:

<template>
<!-- These elements never change -->
<div v-once>
<h1 class="text-center">Bananas for sale</h1>
<p>
Come get this wonderful fruit!
</p>
<p>
Our bananas are always the same price — ${{ banana.price }} each!
</p>

<div class="rounded p-4 bg-yellow-200 text-black">

<h2>
Number of bananas in stock: as many as you need
</h2>
<p>
That's right, we never run out of bananas!
</p>
</div>

<p>
Some people might say that we're... bananas about bananas!
</p>
</div>
</template>

This can be a helpful performance optimization if you need it. The v-once directive tells Vue to
evaluate it once and never update it again. After the initial update it’s treated as fully static content.

Here are the docs for v-once.

VUE TIPS COLLECTION    178

 100.
When should you use v-if?

Instead of using v-if , it’s sometimes more performant to use v-show instead:

<ComplicatedChart v-show="chartEnabled" />

When v-if is toggled on and off, it will create and destroy the element completely. Instead,
v-show will create the element and leave it there, hiding it by setting its style to display:
none .

Doing this can be much more efficient if the component you’re toggling is expensive to render.

On the flip side, if you don’t need that expensive component immediately, use v-if so that it
will skip rendering it and load the page just a bit faster.

179   TEMPLATE TIDBITS
7 All the
Others
These didn’t fit neatly in another category,
but they’re still useful!
 101.
Aria roles you didn’t know you needed

Aria roles are used to tell a screenreader what an element is for.

This is really important when the native HTML element just doesn’t exist (eg. roles like
toolbar and alert ) or when you’re using a different HTML element for design or technical
reasons (eg. wrapping a radio button to style it).

But please, remember that you should always use the semantic element where you can. This is
always the best and most effective solution.

There are six different categories of aria roles:

1. Widget - roles like button , checkbox , separator , tab or scrollbar

2. Composite - roles like combobox and listbox (these are for dropdown menus),
radiogroup , or tree

3. Document structure - this includes article , presentation , figure , feed , and

directory

4. Landmark - banner , main , navigation , and region are roles in this category

5.  ive region - alert , log , marquee , and status are roles that might update
L
with
real-time information

6. Window - alertdialog and dialog are the only two roles in this category

You can check out the full list here.

181    ALL THE OTHERS

102.
A better way to handle errors (and warnings)

You can provide a custom handler for errors and warnings in Vue:

// Vue 3
const app = createApp(App);
app.config.errorHandler = (err) => {
alert(err);
};

// Vue 2
Vue.config.errorHandler = (err) => {
alert(err);
};

Bug tracking services like Bugsnag and Rollbar hook into these handlers to log errors, but you
can also use them to handle errors more gracefully for a better UX.

For example, instead of the application crashing if an error is unhandled, you can show a full-
page error screen and get the user to refresh or try something else.

The warning handler in both versions only works in development.

I created a demo showing how this works. It uses Vue 3, but as seen above, it works nearly the
same in Vue 2:

Error Handler Demo

VUE TIPS COLLECTION    182

 103.
Components are Functions

Underneath it all, components are just functions that return some HTML.

It’s a huge simplification, and if you’ve ever looked at the complexity of the Vue codebase you
know this isn’t actually true. But, fundamentally, this is what Vue is doing for us — plus a mil-
lion other amazing things.

Take a look at this component:

<template>
<div>
<h1>{{ title }}</h1>
<p>Some words that describe this thing</p>
<button>Clickity click!</button>
</div>
</template>

Now, here is some Javascript that does essentially the same thing:

function component(title) {
let html = '';
html += '<div>';
html += '<h1>${title}</h1>';
html += '<p>Some words that describe this thing</p>';
html += '<button>Clickity click!</button>';
html += '</div>';
return html;
}

183    ALL THE OTHERS

This code constructs the HTML in much the same way that the Vue component would.

Granted, we don’t get reactivity, event handling, or a bunch of other features with this, but the
HTML that gets output is the same thing.

This means that we can apply all of the patterns and experience from Javascript (and other
languages) to our components. Things like breaking components down into smaller pieces,
naming them well, and avoiding over-abstraction are all examples.

Of course, there are many more!

VUE TIPS COLLECTION    184

 104.
Destructuring and Reactivity

Destructuring a value from a reactive object will break reactivity:

const myObj = reactive({ prop1: 'hello', prop2: 'world' });

const { prop1 } = myObj;
// prop1 is just a plain String here

The reactivity comes from the object itself and not the property you’re grabbing.

You must use toRefs to convert all of the properties of the object into refs first, and then
you can destructure without issues. This is because the reactivity is inherent to the ref that
you’re grabbing:

const myObj = reactive({ prop1: 'hello', prop2: 'world' });

const { prop1 } = toRefs(myObj);
// Now prop1 is a ref, maintaining reactivity

Using toRefs in this way lets us destructure our props when using script setup without
losing reactivity:

const { prop1, prop2 } = toRefs(defineProps({

prop1: {
type: String,
required: true,
},
prop2: {
type: String,
default: 'World',
},
}));

185    ALL THE OTHERS

105.
Get rid of the double curly braces

You can configure the Vue compiler to use different delimiters instead of the default {{ and
}} .

<template>
<span>|| isBlue ? 'Blue!' : 'Not blue' ||</span>
</template>

This allows you to avoid any conflicts with server-side frameworks:

<template>
<span>${ isBlue ? 'Blue!' : 'Not blue' }</span>
</template>

This can be done through the compiler options. Depending on how your project is set up,
these options are passed to either vue-loader , vite , or the in-browser template compiler.

Learn more from the docs.

VUE TIPS COLLECTION    186

 106.
Force Vue to Re-Render Correctly

If you find yourself needing to force Vue to re-render a component, chances are the reactivity
in your app is broken somewhere.

But, if you have a valid use case, forceUpdate is not working, or you simply need to get
things working quickly, the best way to do this is through the Key Changing Technique:

<template>
<MyComponent :key="componentKey" />
</template>
<script setup>
import { ref } from 'vue';
const componentKey = ref(0);
const changeKey = () => {
componentKey.value += 1;
};
</script>

Here’s how you’d do it with the Options API if you’re not using Vue 3 or not using the Composi-
tion API:

export default {
data() {
return {
componentKey: 0,
};
},
methods: {
changeKey() {
this.componentKey += 1;
}
}
}

187    ALL THE OTHERS

Using the key attribute lets us give Vue more information so it can correctly remove and
replace DOM elements on the page. Because of the reactivity system, Vue can get confused
about which elements need to be replaced in the DOM and which need to stay.

When we change the value of our key , Vue knows that this is a “new” component. It will de-
stroy the existing component and then create and mount an entirely new one.

Problem solved!

But before you reach for this solution, make sure that there isn’t a reactivity issue in your appli-
cation. This should only be used as a last resort, and is not a recommended approach.

VUE TIPS COLLECTION    188

 107.
Forcing a Component to Update

What do you do if a component isn’t updating the way it should?

Likely, this is caused by a misunderstanding and misuse of the reactivity system.

But let’s look at a quick solution using forceUpdate :

import { getCurrentInstance } from 'vue';

const methodThatForcesUpdate = () => {
// ...
const instance = getCurrentInstance();
instance.proxy.forceUpdate();
// ...
};

Using the Options API instead:

export default {
methods: {
methodThatForcesUpdate() {
// ...
this.$forceUpdate(); // Notice we have to use a $ here
// ...
}
}
}

Now, here comes the sledgehammer if the previous approach doesn’t work.

I do not recommend using this approach. However, sometimes you just need to get your
code to work so you can ship and move on.

189    ALL THE OTHERS

But please, if you do this, keep in mind this is almost always the wrong way, and you’re adding
tech debt in to your project.

We can update a componentKey in order to force Vue to destroy and re-render a component:

<template>
<MyComponent :key="componentKey" />
</template>
<script setup>
import { ref } from 'vue';
const componentKey = ref(0);
const forceRerender = () => {
componentKey.value += 1;
};
</script>

The process is similar with the Options API:

export default {
data() {
return {
componentKey: 0,
};
},
methods: {
forceRerender() {
this.componentKey += 1;
}
}
}

You can find a deeper explanation here.

VUE TIPS COLLECTION    190

 108.
Hybrid API: Composition API + Options API

You don’t have to decide between Options API and Composition API, you can use both:

export default {
setup() {
const darkMode = ref(false);
return { darkMode }
},
methods: {
saveDarkMode() {
localStorage.setItem('dark-mode', this.darkMode);
},
}
};

Although you can access Composition API from the Options API, it’s a one-way street. The Com-
position API cannot access anything defined through the Options API:

export default {
setup() {
const darkMode = ref(false);
return { darkMode }
},
methods: {
changeTheme(val) {
// This WILL NOT access the ref defined above
this.darkMode = val;
}
}
};

191    ALL THE OTHERS

This can be useful for incremental adoption of the Composition API, because it lets you use
reusable composables in your Options API.

But mixing two styles of writing components is likely to cause more headaches than it solves,
so please think twice before doing this!

VUE TIPS COLLECTION    192

 109.
What are all these loops for?

I always forget this, so this tip is mostly for me — hopefully, I won’t have to keep looking this
up!

We have 3 types of for loops in Javascript:

1. for...in

2. for...of

3. for

But how do you know which one to use?

For iterating through properties of an object, use for...in :

const numbers = {
'one': 1,
'two': 2,
'three': 3,
};

// We get the properties of the object, not the values

for (const number in numbers) {
console.log(number);
}

// Prints: 'one' 'two' 'three'

Items in a list (also called an iterable object) like an Array or Set, we use for...of :

193    ALL THE OTHERS

 const numbers = ['one', 'two', 'three'];

// We get each of the elements in the Array

for (const number of numbers) {
console.log(number);
}

// Prints: 'one' 'two' 'three'

You can use for...in with an Array since all the indices are just the object’s properties. But
you may not get them in the correct order, and you’ll also get any other properties the Array
has :/

And you know how to use a regular old for loop, which lets you have a lot more control
with some extra typing.

VUE TIPS COLLECTION    194

 110.
Lightweight State Management

We can add computed and methods directly on to a reactive object:

const counter = reactive({

count: 0,
increment() {
this.count += 1;
},
decrement() {
this.count -= 1;
},
});

This works because this is set to the object that the method is accessed through, which
happens to be the reactive object.

Vue’s reactivity system uses Proxies to watch for when a property is accessed and updated. In
this case, we have a small overhead from accessing the method as a property on the object,
but it doesn’t trigger any updates.

If we had a whole series of counters we can reuse this over and over:

const listOfCounters = [];

for (const i = 0; i < 10; i++) {
const counter = reactive({
id: i,
count: 0,
increment() {
this.count += 1;
},

195    ALL THE OTHERS

 decrement() {
this.count -= 1;
},
})
listOfCounters.push(counter);
}

In our template we can use the counters individually:

<div v-for="counter in listOfCounters" :key="counter.id">

<button @click="counter.decrement()">-</button>
{{ counter.count }}
<button @click="counter.increment()">+</button>
</div>

Instead of making the entire object reactive, we can use ref to make only our state reactive:

const counter = {
count: ref(0),
increment() {
this.count.value += 1;
},
decrement() {
this.count.value -= 1;
},
};

This saves us a small and likely unnoticeable overhead. But it also feels somewhat better since
we’re being more thoughtful with our use of reactivity instead of spraying it everywhere.

Here’s our example from before, but this time I’m going to add in a factory function to make it
more readable:

VUE TIPS COLLECTION    196

 const createCounter = (i) => ({
id: i,
count: ref(0),
increment() {
this.count.value += 1;
},
decrement() {
this.count.value -= 1;
},
});

const listOfCounters = [];

for (const i = 0; i < 10; i++) {
listOfCounters.push(createCounter(i));
}

Of course, we can use a factory method with the previous reactive method as well.

197    ALL THE OTHERS

111.
Multi-file single-file components

Here’s a little-known feature of SFC.

You can import files just like you would with a regular HTML file:

<!-- A "single" file component -->

<template src="./template.html"></template>
<script src="./script.js"></script>
<style scoped src="./styles.css"></style>

This can come in really handy if you need to share styles, docs, or anything else. Also perfect
for that super long component file that’s wearing out your finger from all the scrolling...

Here’s a working demo of it in action.

VUE TIPS COLLECTION    198

 112.
Performance Tracing

Vue allows you to do performance tracing to help you debug any performance issues:

const app = createApp({});

app.config.performance = true;

Once you do this, you can use the official Vue Devtools to debug your app’s performance.

199    ALL THE OTHERS

113.
Refresh a Page in Vue

If you need to force a reload your entire page using Vue, all you need is some Javascript:

window.location.reload();

But this is a code smell — you should almost never need to use this method.

Instead, a better solution might be one of these:

•  reate a method to reset and initialize state instead of relying on onMounted hooks
C
or the top-level of setup . You can also create an initialize action for Pinia.

• Make sure your important state is reactive. This tends to fix a lot of common issues.

•  ey-changing — by changing just the key attribute on a specific component, you can
K
force just one component to reload instead of your entire app. Still a bit of a hack, but it
gets the job done.

VUE TIPS COLLECTION    200

 114.
Stacking contexts

If you’ve ever run into an issue with z-index not working as you expect, there’s a good
chance it’s because of stacking contexts.

The browser will stack elements based on their order in the DOM and their z-index . But
it also groups elements into stacking contexts. These are groups of elements that the browser
treats as a single unit.

If two elements are in different stacking contexts, adjusting their z-index will not change
how they stack. You have to adjust how their stacking contexts are stacking:

<body>
<!-- First stacking context -->
<div class="stacking-context">
<div id="a"></div>
<div id="b"></div>
</div>
<!-- Second stacking context -->
<div class="stacking-context">
<div id="c"></div>
<div id="d"></div>
</div>
</body>

<style>
/* These styles won't change anything */
#a { z-index: 1; }
#c { z-index: 2; }
#b { z-index: 3; }
#d { z-index: 4; }
</style>

201    ALL THE OTHERS

Because the second stacking context is above the first, we cannot get #a to be above #c .
The stacking contexts overrule no matter how hard we try with z-index or anything else.

However, if we change the z-index of the stacking contexts, we can get #a and #b to
appear above #c and #d .

If we wanted to order them #a , #c , #b , #d , we’d have to change the HTML structure

and move them all in to the same stacking context:

<body>
<!-- A regular div -->
<div>
<div id="a"></div>
<div id="b"></div>
</div>
<!-- Nothing special about this div -->
<div>
<div id="c"></div>
<div id="d"></div>
</div>
</body>

<style>
/* These will change the visual hierarchy */
#a { z-index: 1; }
#c { z-index: 2; }
#b { z-index: 3; }
#d { z-index: 4; }
</style>

You know a bit about stacking contexts, but what causes them, and how can you control them?

Unfortunately, the rules for creating them are not that straightforward, but well worth learning.

VUE TIPS COLLECTION    202

 115.
Start with the Interface

When writing a composable, don’t immediately dive into implementing it.

Instead, take a moment to figure out how you will be using the component. Take some time to
think about the interface between the composable and the rest of your app.

A few minutes upfront can save you a lot of tears and frustration later on.

Here are a few questions you may want to ask yourself before starting:

1. What arguments should the composable receive?

2. What options do we want to include?

3. What does the composable return?

4. Do we want to use dynamic return values here?

5. What does the minimum useful version look like, and how quickly can we get there?

What does the final version look like? Is there anything easy we can do now to prepare for
that?

Of course, your composable will change and evolve over time.

But it’s much easier to start off heading in the right direction.

203    ALL THE OTHERS

116.
Using two script blocks

The <script setup> sugar in Vue 3 is a really nice feature, but did you know you can use it
and a regular <script> block?

<script setup>
// Composition API
import { ref } from 'vue';
console.log('Setting up new component instance');
const count = ref(0);
</script>
<script>
// ...and the options API too!
export default {
name: 'DoubleScript',
};
</script>

This works because the <script setup> block is compiled into the component’s setup()
function.

There are a few reasons why you might want to do this:

• Use the options API — not everything has an equivalent in the composition API, like
inheritAttrs . For these you can also use defineOptions .

• Run setup code one time — because setup() is run for every component, if you
have code that should only be executed once, you can’t include it in <script setup> .
You can put it inside the regular <script> block, though.

• Named exports — sometimes, it’s nice to export multiple things from one file, but you
can only do that with the regular <script> block.

Check out the docs for more info.

VUE TIPS COLLECTION    204

 117.
UI states to get right

When building a UI, there are many different states that you need to consider:

• Normal — Sometimes called the “happy path,” this is when things are working as
expected. For example, in an email client, you’d show some read emails, some unread
emails, and maybe a few that are in the “spam” folder.

• Loading — Your UI has to do something while getting the data, right? A couple tricks:

1.  se a computed prop to combine multiple loading states — you don’t want spin-
U
ners all over the page.

2.  ait about 200ms before showing a spinner. If the data loads before that, it
W
feels faster than if you quickly flash the loading spinner on and then off again.

•  rror — Things will go wrong, and you need to handle that gracefully. Effectively com-
E
municating problems to users to help them get unstuck is very tricky (don’t make me
guess the password requirements!). Hopefully, you have a good UX designer.

•  mpty — What happens when you have no emails to read, have completed all your
E
tasks, or haven’t uploaded any videos yet? A chart showing the “Last 30 Days” of data
will probably look weird with no data.

•  artial Data — Often similar to the empty state, but your big table with filtering and
P
sorting also needs to work with only two rows of data. The list of emails shouldn’t break
with only one email in it.

•  ots of data — Okay, now you have 1294 unread emails. Does your UI break? Maybe
L
that infinite scrolling doesn’t make as much sense as when there were only 42 emails.

205    ALL THE OTHERS

118.
Check Vue’s Version

Did you know that you can easily check the version of Vue at runtime?

import { version } from 'vue';

if (version.split('.')[0] === '2') {

console.log('Uh, this app is gonna crash.');
console.log('Upgrade to Vue 3!');
}

VUE TIPS COLLECTION    206