DEV Community: Michael Thiessen

13 Vue Composables Tips You Need to Know

Michael Thiessen — Fri, 10 Jan 2025 15:42:00 +0000

Vue composables are incredibly powerful, but they can quickly become messy and hard to maintain if you're not careful.

That's why I've identified 13 tips that will help you write better, more maintainable composables.

Whether you're building a simple state management solution or complex shared logic, these tips will help you:

Avoid common pitfalls that lead to spaghetti code
Write composables that are easier to test and maintain
Create more flexible and reusable shared logic
Gradually migrate from Options API to Composition API if you need to

The tips you'll learn are:

Avoid Prop Drilling Through Multiple Components
Share Data Between Unrelated Components
Control State Updates with Clear Methods
Break Up Large Components into Smaller Functions
Separate Business Logic from Vue Reactivity
Handle Both Sync and Async Data in One Function
Make Function Parameters More Descriptive
Prevent Undefined Options with Default Values
Return Simple or Complex Values Based on Needs
Separate Different Logic Paths into Their Own Functions
Handle Reactive and Raw Values Consistently
Simplify Ref Unwrapping
Migrate from Options API to Composition API Gradually

Let's dive into each pattern and see how they can improve your Vue applications.

And don't forget, comment below with your favourite tip!

1. Avoid Prop Drilling Through Multiple Components

The Data Store Pattern can help avoid passing props and events through multiple component layers.

One situation is where you have a parent and child communicating through endless prop drilling and event bubbling:

<!-- Parent.vue -->
<template>
  <!-- But many more layers of components -->
  <Child :user="user" @change="onUserChange" />
</template>

<script setup>
const user = ref({ name: 'Alice' })
function onUserChange(updatedUser) {
  user.value = updatedUser
}
</script>

This creates a lot of complexity since those props and events have to move back and forth through the component hierarchy.

A more straightforward solution is to create a shared data store that any component can import:

import { reactive, toRefs } from 'vue'
const state = reactive({ user: { name: 'Alice' } })

export function useUserStore() {
  return toRefs(state)
}

2. Share Data Between Unrelated Components

The Data Store Pattern also helps when sibling or “cousin” components need to share the same data without any direct connection.

Suppose two siblings both require the same user object, but there's no elegant path for props or events.

This often results in awkward data juggling through a parent or duplicated state.

A better approach is to rely on a single composable store that both siblings can consume:

// SiblingA.vue
import { useUserStore } from './useUserStore'
const { user } = useUserStore()

// SiblingB.vue
import { useUserStore } from './useUserStore'
const { user } = useUserStore()

3. Control State Updates with Clear Methods

The Data Store Pattern encourages providing clear methods for updating shared state.

Some developers expose the entire reactive object to the world, like this:

export const user = reactive({ darkMode: false })

That lets anybody change the user’s darkMode property directly from any file, which can lead to scattered, uncontrolled mutations.

A better idea is to return the state as read only along with functions that define how updates happen:

import { reactive, readonly } from 'vue'
const state = reactive({ darkMode: false })

export function toggleDarkMode() {
  state.darkMode = !state.darkMode
}

export function useUserStore() {
  return {
    darkMode: readonly(state.darkMode),
    toggleDarkMode
  }
}

4. Break Up Large Components into Smaller Functions

The Inline Composables Pattern helps break up large components by gathering related state and logic into smaller functions.

A giant component might put all its refs and methods in one place:

<script setup>
const count = ref(0)
const user = ref({ name: 'Alice' })
// 500 more lines of intertwined code with watchers, methods, etc.
</script>

That setup quickly becomes unmanageable.

Instead, an inline composable can group logic and provide it locally. We can then extract it into a separate file later on:

<script setup>
function useCounter() {
  const count = ref(0)
  const increment = () => count.value++
  return { count, increment }
}

const { count, increment } = useCounter()
</script>

5. Separate Business Logic from Vue Reactivity

The Thin Composables Pattern tells us to separate raw business logic from Vue reactivity so tests and maintenance become simpler.

You might embed all logic in the composable:

export function useCounter() {
  const count = ref(0)
  function increment() {
    count.value = (count.value * 3) / 2
  }
  return { count, increment }
}

That forces you to test logic inside a Vue environment.

Instead, keep the complicated rules in pure functions and let the composable only handle reactive wrappers:

// counterLogic.js
export function incrementCount(num) {
  return (num * 3) / 2
}

// useCounter.js
import { ref } from 'vue'
import { incrementCount } from './counterLogic'

export function useCounter() {
  const count = ref(0)
  function increment() {
    count.value = incrementCount(count.value)
  }
  return { count, increment }
}

6. Handle Both Sync and Async Data in One Function

The Async + Sync Composables Pattern merges both synchronous and asynchronous behaviors into one composable instead of creating separate functions.

This is just like how Nuxt's useAsyncData works.

Here we have a single composable that can return a promise while also giving immediate reactive properties for synchronous usage:

import { ref } from 'vue'

export function useAsyncOrSync() {
  const data = ref(null)
  const promise = fetch('/api')
    .then(res => res.json())
    .then(json => {
      data.value = json
      return { data }
    })
  return Object.assign(promise, { data })
}

7. Make Function Parameters More Descriptive

The Options Object Pattern can clear up long lists of parameters by expecting a single config object.

Calls like this are cumbersome and prone to mistakes, and adding new options requires updating the function signature:

useRefHistory(someRef, true, 10, 500, 'click', false)

It’s not obvious what each argument stands for.

A composable that accepts an options object keeps everything descriptive:

useRefHistory(someRef, {
  deep: true,
  capacity: 10,
  throttle: 500,
  eventName: 'click',
  immediate: false
})

8. Prevent Undefined Options with Default Values

The Options Object Pattern also recommends default values for each property.

A function that assumes certain fields exist can be problematic if they aren’t passed:

export function useRefHistory(someRef, options) {
  // potential undefined references here
}

It’s better to destructure options with safe defaults:

export function useRefHistory(someRef, {
  deep = false,
  capacity = Infinity,
  ...rest
} = {}) {
  // can safely use deep, capacity, etc.
}

9. Return Simple or Complex Values Based on Needs

The Dynamic Return Pattern makes sure a composable can return either a single value for simple use cases or an expanded object with more advanced controls.

Some approaches always return an object with everything:

export function useLocalStorage(key, defaultValue) {
  const val = ref(defaultValue)
  function remove() { /* ... */ }
  return { val, remove }
}

Anyone who only needs the main reactive value is forced to deal with extra stuff.

A composable that conditionally returns a single ref or an object solves that:

export function useLocalStorage(key, defaultValue, { controls = false } = {}) {
  const value = ref(defaultValue)
  function remove() { /* ... */ }
  return controls ? { value, remove } : value
}

10. Separate Different Logic Paths into Their Own Functions

The Hidden Composables Pattern helps avoid mixing mutually exclusive logic in the same composable.

Some code lumps together multiple modes or code paths:

export function useUserFlow() {
  // admin logic
  // guest logic
}

Splitting each path into its own composable is much clearer and doesn't affect functionality:

export function useAdminFlow() {
  // admin-only logic
}

export function useGuestFlow() {
  // guest-only logic
}

11. Handle Reactive and Raw Values Consistently

The Flexible Arguments Pattern ensures inputs and outputs in composables are uniformly handled as reactive data or raw values, avoiding confusion.

Some code checks if an input is a ref or not:

export function useSomething(input) {
  if (isRef(input)) {
    // ...
  } else {
    // ...
  }
}

Instead, you can convert right away.

By using ref, if the input is a ref, that ref will be returned. Otherwise, it will be converted to a ref:

import { ref, toValue } from 'vue'

export function useSomething(input) {
  const asRef = ref(input)       // always a ref
}

12. Simplify Ref Unwrapping

The Flexible Arguments Pattern also uses toValue when unwrapping is needed.

Without it, code might keep doing isRef checks:

export function useLogger(msg) {
  // if (isRef(msg)) ...
  // else ...
}

It’s much simpler to call:

import { toValue } from 'vue'
export function useLogger(msg) {
  const val = toValue(msg)
  console.log(val)
}

13. Migrate from Options API to Composition API Gradually

The Options to Composition Pattern lets you migrate big Options API components into the Composition API step by step in an incremental way that's easy to follow.

A classic Options component might do this:

export default {
  data() {
    return { count: 0 }
  },
  computed: {
    double() { return this.count * 2 }
  },
  methods: {
    increment() { this.count++ }
  }
}

Data, computed properties, and methods are scattered.

Converting it to script setup pulls them together and makes it easier to follow, and allows you to use these patterns:

<script setup>
const count = ref(0)
const double = computed(() => count.value * 2)
function increment() {
  count.value++
}
</script>

Wrapping it up

These 13 tips will help you write better Vue composables that are easier to maintain, test, and reuse across your applications.

But we're just scratching the surface here.

Over the years, I've collected many more patterns and tips, and I've put them all into an in-depth course on composable patterns.

It covers 16 patterns in total, and each pattern has:

In-depth explanations — when to use it, edge cases, and variations
Real-world examples — so you can see how to use them beyond these simple examples
Step-by-step refactoring examples — so you can see how to apply them to your own code

Go here to learn more.

Oh, and this course is on sale until January 15th, so you can get it for a great discount right now!

Check out Composable Design Patterns

Ref vs. Reactive — Which is Best?

Michael Thiessen — Wed, 22 Feb 2023 15:41:15 +0000

A huge thanks to everyone who looked at early drafts of this: especially Austin Gil for challenging my arguments, Eduardo San Martin Morote, Daniel Roe, Markus Oberlehner, and Matt Maribojoc

This has been a question on the mind of every Vue dev since the Composition API was first released:

What’s the difference between ref and reactive, and which one is better?

My extremely short answer is this: default to using ref wherever you can.

Now, that’s not a very satisfying answer, so let’s take some more time to go through all of the reasons why I think ref is better than reactive — and why you shouldn’t believe me.

Here’s what our journey will look like, in roughly three acts:

Act 1: The differences between ref and reactive — First, we’ll go through all of the ways that ref and reactive are different. I’ll try to avoid giving any judgment at this point so you can see all the ways they’re different.
Act 2: The ref vs reactive debate — Next, I’ll lay out the main arguments for ref and for reactive, giving the pros and cons of each. At this point you will be able to make your own well-informed decision.
Act 3: Why I prefer ref — I end the article stating my own opinion and sharing my own strategy. I also share what others in the Vue community think about this whole debate, since one person’s opinion only counts for so much (ie. very little).

More than just a discussion of “ref vs. reactive”, I hope that as we explore this question you’ll come away with additional insights that will improve your understanding of the Composition API!

Also, this is a long article, so if you don’t have time to read it all now, definitely set this aside and come back to it — you’ll thank me later!

tl;dr — My highly opinionated and simple strategy

But first, a quick summary of my strategy for choosing.

With roughly increasing levels of complexity:

Start with using ref everywhere
Group related things with reactive if you need to
Take related state — and the methods that operate on them — and create a composable for them (or better yet, create a store in Pinia)
Use reactive where you want to “reactify” some other JS object like a Map or Set.
Use shallowRef and other more use-case-specific ref functions for any necessary edge cases.

Act 1: The differences between ref and reactive

First, I want to take some time to specifically discuss how ref and reactive are different, and their different uses in general.

I’ve tried to be exhaustive in this list. Of course, I’ve probably missed some things — please let me know if you know of something I haven’t included!

With that out of the way, let’s look at some differences between these two tools we’ve been given.

Dealing with .value

The most obvious distinction between ref and reactive is that while reactive quietly adds some magic to an object, ref requires you to use the value property:

const reactiveObj = reactive({ hello: 'world' });
reactiveObj.hello = 'new world';

const refString = ref('world');
refString.value = 'new world';

When you see something.value and you’re already familiar with how ref works, it’s easy to understand at a glance that this is a reactive value. With a reactive object, this is not necessarily as clear.

// Is this going to update reactively?
// It's impossible to know just from looking at this line
someObject.property = 'New Value';

// Ah, this is likely a ref
someRef.value = 'New Value';

But here are some caveats:

If you don’t already understand how ref works, seeing .value means nothing to you. In fact, for someone new to the Composition API, reactive is a much more intuitive API.
It’s possible that non-reactive objects have a value property. But because this clashes with the ref API I would consider this an anti-pattern, whether or not you like using ref.

This is actually the difference that this entire debate hinges on — but we’ll get to that later.

The important thing to remember for now is that using either ref or reactive requires us to access a property.

Tooling and Syntax Sugar

The main disadvantage of ref here is that we have to write out these .value accessors all over the place. It can get quite tedious!

Fortunately, we have some extra tools that can help us mitigate this problem:

Template unwrapping
Watcher unwrapping
Volar

In many places Vue does this unwrapping of the ref for us, so we don’t even need to add .value. In the template we simply use the name of the ref:

<template>
  <div>{{ myRef }}</div>
</template>

<script setup>
const myRef = ref('Please put this on the screen');
</script>

And when using a watcher we specify the dependencies we want to be tracked, we can use a ref directly:

import { watch, ref } from 'vue';

const myRef = ref('This might change!');

// Vue automatically unwraps this ref for us
watch(myRef, (newValue) => console.log(newValue));

Lastly, the Volar VS Code extension will autocomplete refs for us, adding in that .value wherever it’s needed. You can enable this in the settings under Volar: Auto Complete Refs:

You can also enable it through the JSON settings:

"volar.autoCompleteRefs": true

It is disabled by default to keep the CPU usage down.

ref uses reactive internally

Here’s something interesting you may not have realized.

When you use an object (including Arrays, Dates, etc.) with ref, it’s actually calling reactive under the hood.

Anything that isn’t an object — a string, a number, a boolean value — and ref uses its own logic.

You can see it working in these two lines:

Line 1: Creating a ref involves calling toReactive to get the internal value
Line 2: toReactive only calls reactive if the passed value is an object

// Ref uses reactive for non-primitive values
// These two statements are approximately the same
ref({}) ~= ref(reactive({}))

Reassigning Values

Vue developers for years have been tripped up by how reactivity works when reassigning values, 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.

You see, reactive values cannot be reassigned how you’d 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.

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.

Reassigning values will not trigger the reactivity system. You must modify a property on an existing object.

This also applies to refs, but this is made a little easier because of the standard .value property 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]"

Both ref and reactive are required to access a property to keep things reactive, so no real difference there.

But, where this is the expected way of using a ref, it’s not how you would expect to use reactive. It’s very easy to incorrectly use reactive in this way and lose reactivity without realizing what’s happening.

Template Refs

Reassigning values can also cause some 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 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 function 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"

Alex Vipond wrote a fantastic book on using the function ref pattern to create highly reusable components in Vue (something I know quite a bit about). It’s eye-opening, and I’ve learned a ton from this book, so do yourself a favour and grab it here: Rethinking Reusability in Vue

Destructuring Values

Destructuring a value from a reactive object will break reactivity, since the reactivity comes from the object itself and not the property you’re grabbing:

const myObj = reactive({ prop1: 'hello', prop2: 'world' });
const { prop1 } = myObj;

// prop1 is just a plain String here

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',
  },
}));

Composing ref and reactive

One interesting pattern is combining ref and reactive together.

We can take a bunch of refs and group them together inside of a reactive object:

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);

We’re able to use the reactive object as we’d expect, but we can also reactively update the underlying refs even without accessing the reactive object we’ve created. However you access the underlying properties, they reactively update everything else that’s “hooked up” to it.

I’m not sure this pattern is better than simply putting a bunch of refs in a plain JS object, but it’s there if you need it.

Organizing State with Ref and Reactive

One of the best uses for reactive is to manage state.

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');

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

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

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).

However, an even better solution for grouping related pieces of reactive state might be to create 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.

Not only can we group our state together, but it’s even more explicit that these are things that go together. And since we’re returning an object of refs from our composable (you’re doing that, right?) we can use each piece of state individually if we want.

We have the added benefit that we can co-locate methods with our composable, too. So state changes and other business logic can be centralized and easier to manage.

Of course, this may be a little more than what you need, in which case using reactive is perfectly fine. You may also find yourself wondering, “why not just use Pinia for this?”, and you’d certainly have a valid point.

The point is this:

Using reactive gives us another great option for organizing our state.

Wrapping Non-Reactive Libraries and Objects

In talking with Eduardo about this debate, he mentioned that the only time he uses reactive is for wrapping collections (besides arrays):

const set = reactive(new Set());

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

setTimeout(() => {
  set.add('another one');
}, 2000);

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.

Refactoring from Options API to Composition API

It also appears that reactive is really useful when refactoring a component to use the Composition API:

I haven’t tried this myself yet, but it does make sense. We don’t have anything like ref in the Options API, but reactive works very similarly to reactive properties inside of the data field.

Here, we have a simple component that updates a field in component state using the Options API:

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

The simplest way to get this working using the Composition API is to copy and paste everything over using reactive:

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

  // 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. But the benefit of this approach is that it’s straightforward (possibly simple enough to automate with a codemod or something similar?).

They’re just different

After going through all of these examples it should be pretty clear that if we really had to, we could write perfectly fine Vue code with just ref or just reactive.

They’re equally capable — they’re just different.

Keep this in mind as we explore the debate between ref and reactive.

Keep reading Act 2 and Act 3 of this article on my blog.

How to Fix the TypeScript intellisense template error in Vue

Michael Thiessen — Tue, 13 Sep 2022 15:16:04 +0000

I recently got this error while working on a Vue 3 project:

TypeScript intellisense is disabled on template. To enable, configure `"jsx": "preserve"` in the `"compilerOptions"` property of tsconfig or jsconfig. To disable this prompt instead, configure `"experimentalDisableTemplateSupport": true` in `"vueCompilerOptions"` property.volar

No need to panic, just disable this Volar message exactly how it says.

In your .tsconfig file you need to add "jsx": "preserve" in the compilerOptions section:

{
  "compilerOptions": {
    "jsx": "preserve"
  }
}

I’m using Nuxt 3, so my TypeScript config file looks a little different:

{
  // https://v3.nuxtjs.org/concepts/typescript
  "extends": "./.nuxt/tsconfig.json",
  "compilerOptions": {
    "jsx": "preserve"
  }
}

If you’re using a jsconfig file instead, it may look closer to this:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "jsx": "preserve"
  },
  "include": ["src/**/*"]
}

The jsx option on the .tsconfig controls how ts transforms and outputs .tsx files, but this error happens on .vue files with no tsx extension.

So changing this option to silence the warning has no real effect on our projects. In Vue we are only using TypeScript for type checking so this option doesn’t affect anything that we’re doing.

This issue is likely happening because of the TypeScript Language Server that VS Code uses to provide the Intellisense feature. Volar hooks into this server, but unfortunately, has no control over it.

🔥 Vue Tips #31: The limitations of props

Michael Thiessen — Tue, 26 Oct 2021 15:14:51 +0000

This newsletter was sent out to my list on October 20, 2021. Sign up here to get emails like this each week!

As always, here are some tips.

Enjoy.

— Michael

🔥 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="item.selected && '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>

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!

🔥 The limitations of props

Props are useful, but they have two glaring issues:

Impossible to pass markup*
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 has two values for type, you can't just use a third without modifying the Button:

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

// Button.vue
export default {
  props: {
    type: {
      type: String,
      // Unfortunately, 'AWESOME' doesn't work here :/
      validator: val => ['primary', 'secondary'].includes(val),
    }
  }
};

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 fairly open-ended, giving you lots of flexibility. This is why in many cases, slots are simply better than props.

📜 A photoshop plugin with Vue!?

Last week I shared an article on creating a VS Code extension.

Now we break out of the web world entirely, and see how we can create a plugin for Photoshop.

I had no idea this was even possible!

Read it now: Make Your First Plugin with Vue JS for Photoshop and Adobe XD

🗞 Vue.js London is today + tomorrow!

Quick, don't miss out on some amazing talks at Vue.js Conference (London) — happening right now!

Conferences are an amazing place to learn and connect with other Vue devs.

We're slowly starting to see some more in-person events, along with lots of virtual ones too.

Here are some upcoming conferences:

VueConf Toronto — November 22-23 — free + online
Vuejs Global (Amsterdam) — February 10-11, 2022 — Amsterdam

(Let me know if I've missed any.)

💬 Brute force

When in doubt, use brute force. — Steve McConnell

I'm often just not clever enough to come up with a clever solution.

But cleverness isn't the point of software development.

It's developing software that works.

🧠 Spaced-repetition: 6 Levels of Reusability

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

My course on reusable components covers this framework, which outlines six different levels of reusability that you can use in your components.

Here are the six levels of reusability:

Templating — Reusing code by wrapping it up inside of a component
Configuration — Using configuration props to allow for varying behaviour
Adaptability — Allowing components to become future-proof
Inversion — Letting other components control the process
Extension — Using reusability throughout our component
Nesting — Creating powerful hierarchies of components

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

Exclusive tips and insights every week

Join 8335 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #30: Reusability Fundamentals: The Configuration Pattern

Michael Thiessen — Tue, 19 Oct 2021 15:26:53 +0000

This newsletter was sent out to my list on October 13, 2021. Sign up here to get emails like this each week!

Hey there,

I'm still trying to adjust to the darkness this time of year in Canada.

It's dark when I start work at 8, and dark again when I finish around 5. I work in my basement, so I don't get a lot of light during the day either.

So I'm trying to take some time during the day to get outside and get some sunlight (and fresh air).

Do you change your working habits throughout the year? A different schedule during winter or summer?

— Michael

🔥 How I deal with dynamic classes

A pattern I use constantly is triggering classes with boolean flags:

<template>
  <div :class="disabled && 'disabled-component'">
    Sometimes this component is disabled. Other times it isn't.
  </div>
</template>

/* Some styles */
.disabled-component {
  background-color: gray;
  color: darkgray;
  cursor: not-allowed;
}

Either the trigger is a prop I use directly, or a computed prop that tests for a specific condition:

disabled() {
  return this.isDisabled || this.isLoading;
}

If I just need one class on an element, I use the logical AND to trigger it:

<div :class="disabled && 'disabled-component'"></div>

Sometimes it's a decision between two classes, so I'll use a ternary:

<div
  :class="disabled ? 'disabled-component' : 'not-yet-disabled'"
/>

I don't often use more than two classes like this, but that's where an Object or Array comes in handy:

<div
  :class="{
    primary: isPrimary,
    secondary: isSecondary,
    tertiary: isTertiary,
  }"
/>

<div
  :class="[
    isPrimary && 'primary',
    isSecondary && 'secondary',
    isTertiary && 'tertiary',
  ]"
/>

Of course, when it gets complex enough it's better to just have a computed prop that returns a string of class names (or returns an Object or Array):

<div :class="computedClasses" />

🔥 Reusability Fundamentals: The Configuration Pattern

So you've got an awesome 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 color 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.

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 are also part of mastering Configuration, the second level of reusability.

And the other, more interesting levels of reusability?

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

📜 Using Vue for a VS Code extension?

This is a very interesting article on creating your own VS Code extension...

But you get to build the UI using Vue.

It goes into all the steps necessary to set up and get your extension running. From there, the sky is the limit (unless you're building rockets 🚀).

Read it now: Building a VS Code Extension Using Vue.js

🗞 Nuxt 3! Yeah, it's here!

It was officially released yesterday, and comes with some amazing stuff:

Vue 3
Vite
Typescript
and so many other features

Check it out here.

Also, don't forget that Vue.js London is happening next week!

💬 Repeated failure

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. — Dave Parnas

I think Dave is talking about edge cases.

You think you've covered them all, but you never have. Not until real users start using it for real.

🧠 Spaced-repetition: Reducing Objects

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

The reduce function is really great for converting arrays into objects, but it can be intimidating.

If we have a bunch of items that all have an id:

{
  id,
  //...
}

We can reorganize the array into an object, where the key for each item is the item's id:

const obj = arr.reduce((prev, next) => {
  // Grab the id from the item
  const { id } = next;

  // Add the item to our object
  prev[id] = next;

  // Return the object so we can add more items
  return prev;
}, {});

You get an object that looks like this:

{
  'id1': { id: 'id1', ... },
  'id2': { id: 'id2', ... },
  'id3': { id: 'id3', ... },
}

If you want to group all objects in an array by a specific property, you can do something very similar:

const obj = arr.reduce((prev, next) => {
  // Grab the property from the item that we want to group by
  const { prop } = next;

  // Add a new array to the object if this is the first one
  // with this value
  if (prev[prop] === undefined) {
    prev[prop] = [];
  }

  // Add our item to this array
  prev[prop].push(next);

  // Return the object so we can add more items
  return prev;
}, {});

Our final object looks like this:

{
  'prop1': [
    { prop: 'prop1', ... },
    { prop: 'prop1', ... },
    { prop: 'prop1', ... },
  ],
  'prop2': [
    { prop: 'prop2', ... },
    { prop: 'prop2', ... },
    { prop: 'prop2', ... },
  ],
}

Exclusive tips and insights every week

Join 8335 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #29: Component Seams Framework: The easy way to split up components

Michael Thiessen — Tue, 12 Oct 2021 16:00:14 +0000

This newsletter was sent out to my list on October 6, 2021. Sign up here to get emails like this each week!

Heyo,

Do you like hot sauce?

Well, I tried making some last week, and it was an utter failure. So I'll stick with baking bread.

And if you don't like hot sauce, maybe you'll enjoy these hot tips instead.

— Michael

🔥 v-pre and v-once

If you've got large chunks of static or mostly static content, you can tell Vue to ignore it using the v-pre or v-once directives:

<template>
  <!-- These elements never change -->
  <div v-pre>
    <h1 class="text-center">Bananas for sale 🍌</h1>
    <p>
      Come get this wonderful fruit!
    </p>
    <p>
      Our bananas are always the same price — $1 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>

These can be useful performance optimizations if you need them.

With v-pre Vue will treat the element and it's children as static HTML, and won't do any of it's magic on it. The v-once directive tells Vue to evaluate it once, and then never update it again.

Here are the docs for v-pre and v-once.

🔥 Component Seams Framework: The easy way to split up components

Here's a technique for splitting up components:

The code you write forms natural groups. You want to identify these groups, and the seams that run between them.

Once you do that, it's easy to extract components — by keeping things in their natural groups as much as possible.

The Component Seams Framework helps you do that in just three steps:

Find the seams — they can be found in your template, by looking for repeated sections, as well as sections that perform different tasks. You can also find them in your props, state, and computed props, by looking for things that are related and are often updated together.
Stack the seams — take all of the seams you've found, line them up, and you'll start to see where they agree (and where they don't).
Split along the seams — piece by piece, we'll pull things out and then figure out what to do with its dependencies. Either include the dependency in the new component or pass it in to the new component somehow (prop, slot, or event).

This method is covered in more detail in Clean Components if you want to learn more.

📜 25 Vue Tips You Need to Know

I've written 58 Vue tips so far this year for you.

That's 2 every week for 29 weeks (since March 22).

I put 25 of them together for you in this one article (which is one of the top Vue posts of all time on DEV.to).

Read it now: 25 Vue Tips You Need to Know

🗞 Nuxt 3 is nuxt week!

It's coming October 12.

This is going to be huge, and I can't wait to try it out:

Vue 3
Vite
Typescript
and so many other features

Learn more about what's coming with Nuxt 3.

💬 The real problem

Sometimes the problem is to discover what the problem is. — Gordon Glegg

I've wasted so much of my life trying to solve things that weren't actually problems.

Now I try to make sure that what I think is the problem is actually the problem.

It saves me so much time and effort.

🧠 Spaced-repetition: Master computed props

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

When a function does more than just return a value, it makes your code more complicated.

These are called side effects, and you should never have them inside of a computed prop:

export default {
  computed: {
    fullName() {
      this.fetchUserInformation();  // Side effect
      return `${this.firstName} ${this.lastName}`;
    },
  },
};

However, fixing this is quite straightforward. We can just move that side effect into a watcher that is triggered whenever the computed prop updates:

export default {
  computed: {
    fullName() {
      return `${this.firstName} ${this.lastName}`;
    },
  },

  watch: {
    fullName() {
      this.fetchUserInformation();  // Side effect
    },
  },
};

This applies equally to the composition API, although the syntax is slightly different.

At first glance, this may seem like we made the code more complicated. But actually, we've made it a lot simpler.

This concept is expanded on in my course, Clean Components.

Exclusive tips and insights every week

Join 8335 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #28: Easily create component variations with the Base Component pattern

Michael Thiessen — Tue, 05 Oct 2021 13:45:02 +0000

This newsletter was sent out to my list on September 29, 2021. Sign up here to get emails like this each week!

What's up?

You may have noticed that recently I've been experimenting with adding sponsors to this newsletter.

Honestly, I'm not sure I like putting them in here.

It's extra work that I don't particularly enjoy, and I have the feeling it doesn't make the newlsetter better for you either. Of course, if it made boatloads of cash so I could focus more time on this then it would be worth it, but that's just not the case...

I'd rather spend that time on writing better tips for you.

— Michael

🔥 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 can use the instance property $parent:

// Tight coupling like this is usually a bad idea
this.$parent.methodOnParentComponent();

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 it was taken out for Vue 3 (please don't use this one).

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.

In those cases, you don't want to use props and events to connect up a component. Rather, you use provide/inject, $parent, or $root, to automatically connect the components and make things happen.

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.

🔥 Easily create component variations with the Base Component pattern

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

It has a few basic steps:

Create your base component
Wrap it with another component to get a variant of the original
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>

You can use this pattern in many different ways:

Lock down props — take a Button component and hard code a few props to get a DisabledButton. Now you can just use the DisabledButton directly without having to fiddle with all the necessary props each time.
Lock down slots — create an InfoButton variant where the icon passed to the Button is always the same. 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, most of which are for edge cases. Create a BaseButton with all the props, and a Button that passes on only the most common ones. This is a lot safer, easier to use, and the documentation is easier to read too.

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

📜 How do you structure a Vue project?

Just an hour ago, Marco asked me this very question.

My quick response was: keep it flat and simple, and when things start to get messy, slowly add in folders.

An even better response: Markus wrote a great article on this, and he goes into much more detail and provides some more specific advice.

Read his article here: Vue Project Directory Structure

💬 Software Quote

Automating chaos just gives faster chaos. — Mark Fewster

This is the paradox of abstraction:

Creating a component and reusing it over and over can save you a lot of time.

But if that component is wrong or has a bug, you also multiply that problem over and over 🤦‍♂️

🧠 Spaced-repetition: Aria roles you didn't know you needed

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

Aria roles are used to tell a screenreader what an element is for.

This is really important when the native HTML elemen 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:

Widget - roles like button, checkbox, separator, tab, or scrollbar
Composite - roles like combobox and listbox (these are for dropdown menus), radiogroup, or tree
Document structure - this includes article, presentation, figure, feed, and directory
Landmark - banner, main, navigation, and region are roles in this category
Live region - alert, log, marquee, and status are roles that might update with real-time information
Window - alertdialog and dialog are the only two roles in this category

You can check out the full list here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques#roles

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #27: Controlled Props — or How to Override Internal State

Michael Thiessen — Wed, 29 Sep 2021 15:42:59 +0000

This newsletter was sent out to my list on September 22, 2021. Sign up here to get emails like this each week!

Hi!

First, I need to say a huge THANK YOU to all 212 of you who bought Clean Components in the sale that ended last week.

Your support of my work is absolutely astonishing — it's what gives me the motivation to keep creating.

So, it's officially the first day of fall, at least in the northern hemisphere.

Everything seems to be pumpkin-spiced these days:

lattes from Starbucks
scented candles (why)
Cheerios (okay, I'm willing to try that one)

Please tell me this pumpkin obsession is just a North American thing?

I'll spare you from pumpkin-spiced tips though. These ones are just the regular kind 🎃

— Michael

🔥 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 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
      _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.

🔥 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 memoizes) 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 went 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 very often.

It's definitely a useful tool to help you get more performance — when you really need it.

Check out the docs for v-memo.

🔗 (Sponsored) Come work with me at Vidyard

It's where I've learned all that I know about Vue.

We're rapidly growing our remote engineering team and we need intermediate and senior devs in Canada and the US.

Our stack is Vue + GraphQL + Rails (with React, Node, and some other things, too).

You'll get to work on tons of diverse and interesting projects. Some of the things I've worked on:

In-house component library — written in Vue, of couse
Analytics dashboard and pipeline — lots of data, charts, and microservices
That time we rewrote our entire frontend in Vue — yes, we're very committed to paying down tech debt
UI for simple video editing

It's also the best place to work (in my opinion):

In 4 years I've never had to rush to hit a deadline. No evenings, weekends, or stress-induced baldness.
Every dev has their own "sandbox" — a replica of our production environment, running in AWS, complete with hot reloading.
The fundamentals: continuous deployment, e2e testing, mentors that help you grow, a focus on doing things right, very few meetings to interrupt your flow, too many memes, never enough memes.

Apply now and get the best job you've ever had.

📜 I didn't know this about computed props

Computed props may not work exactly how you think they do.

That's what a lot of us are finding out after reading Thorsten's post on a common misconception around rendering and computed props.

It's not something you'll run into every day, but it's good to know about if you run into performance problems.

Read it here: When a computed property can be the wrong tool

💬 Working

The greatest performance improvement of all is when a system goes from not-working to working. — John Ousterhout

First, get it to work. Then get it to work well. Don't worry about how good the code is until it's working — that's what refactoring is for.

It's so much easier to transform bad code into good code if it's already working correctly.

🗞 News: Vue.js Amsterdam update

Unfortunately, Vue.js Amsterdam had to cancel their conference for this October due to COVID, but it's on for February 2022!

Here are some upcoming conferences:

Vue.js Conference (London) — October 20-21 — London and online
VueConf Toronto — November 22-23 — free + online
Vuejs Global (Amsterdam) — February 10-11, 2022 — Amsterdam

🧠 Spaced-repetition: Where do you put shared state?

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

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, when the components sharing state are in separate components, in separate folders, it's harder to see that this is the solution.

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 as well.

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #26: 6 levels of component reusability

Michael Thiessen — Mon, 20 Sep 2021 14:49:37 +0000

This newsletter was sent out to my list on September 15, 2021. Sign up here to get emails like this each week!

Heyo,

Nuxt Nation is happening today (maybe right now depending on when you open this email).

You might still be able to catch some of the action: Nuxt Nation

In the meantime, here are some more tips for ya.

— Michael

🔥 6 Levels of Reusability

My course on reusable components covers this framework, which outlines six different levels of reusability that you can use in your components.

Here are the six levels of reusability:

Templating — Reusing code by wrapping it up inside of a component
Configuration — Using configuration props to allow for varying behaviour
Adaptability — Allowing components to become future-proof
Inversion — Letting other components control the process
Extension — Using reusability throughout our component
Nesting — Creating powerful hierarchies of components

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

🔥 Grid Template Areas

Sometimes complicated layouts are, well, complicated. But using grid-template-areas is here to help!

<section>
  <header>Page header</header>
  <nav>Nav bar</nav>
  <main>Content goes here!</main>
  <footer>Not for your feet</footer>
</section>

With this HTML, you'd first attach grid-area names to each element:

header { grid-area: header; }
nav { grid-area: nav; }
main { grid-area: main; }
footer { grid-area: footer; }

Now you can describe your layout:

section {
  /* ... some other CSS grid set up here */
  grid-template-areas: "header header"
                       "nav    main"
                       "footer footer";
}

And if you need a single column layout for mobile (with the nav at the bottom, just for fun):

section {
  grid-template-areas: "header"
                       "main"
                       "nav"
                       "footer";
}

It's pretty easy to see exactly how the page is being laid out with grid-template-areas.

📜 Helpful Patterns in Vue

Although I disagree with using custom elements to get a flatter component hierarchy, Brennan has a bunch of useful tips and patterns in this article.

I use the loading state one all the time.

Read it here: Helpful Patterns I Use in Vue

🗞 News: Nuxt Nation is TODAY

Don't miss it!

We also have three more conferences coming up in the next 2 months, all accessible online and two offering (limited) in-person experiences:

Vuejs Global (Amsterdam) — October 1st and 4th — Amsterdam and online
Vue.js Conference (London) — October 20-21 — London and online
VueConf Toronto — November 22-23 — free + online

💬 Two Types of Languages

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." — Bjarne Stroustrup

🧠 Spaced-repetition: Vue Testing Library

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

One of my favourite tools for testing is Vue Testing Library:

test('displays correct text', () => {
  const { getByText } = render(MyComponent);
  getByText(/Fail the test if this text doesn't exist/);
})

It builds on top of vue-test-utils, making it easier to write tests that are closer to how users actually interact with your app.

Users look for specific text, or look for a button to click. They don't look for the nth child of a div with the class .booking-card-container.

Writing tests this way makes them easier to understand, simpler to write, and more robust against changes to your code. Nothing about this test is concerned with the implementation, so it's unlikely to break even under a heavy refactor.

If this idea is new to you, I highly encourage you to read more about the Testing Library guiding principles.

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #25: Reduce, reuse, recursion?

Michael Thiessen — Thu, 09 Sep 2021 12:24:40 +0000

This newsletter was sent out to my list on September 8, 2021. Sign up here to get emails like this each week!

Hey there,

Today we're talking reduce, dependency injection, React (don't worry, this is still a Vue newsletter), code comments, and conferences.

But you don't have to take my word for it.

And just to keep you in the loop: right now there's a 35% off sale happening for Clean Components. It ends September 13 at midnight (EDT).

— Michael

🔥 Simpler testing with dependency injection

Jest makes it easy to mock or stub out functions, but you can also use dependency injection to make things easy to stub:

export default {
  props: {
    // Returns text to be displayed
    someMethod: {
      type: Function,
      required: true,
    },
  },
};

it('should work', () => {
  const { getByText } = render(MyComponent, {
    props: {
      someMethod() {
        return 'Test text';
      },
    },
  });
  getByText(/Test text/);
});

If it's coming from outside of the component, it's pretty straightforward to stub it out or mock it however you need, in order to get the test to do what you want.

You can do this in a variety of ways, depending on your use case:

props
provide/inject
Vuex
custom plugin

(There are probably many more)

🔥 Reducing Objects

The reduce function is really great for converting arrays into objects, but it can be intimidating.

If we have a bunch of items that all have an id:

{
  id,
  //...
}

We can reorganize the array into an object, where the key for each item is the item's id:

const obj = arr.reduce((prev, next) => {
  // Grab the id from the item
  const { id } = next;

  // Add the item to our object
  prev[id] = next;

  // Return the object so we can add more items
  return prev;
}, {});

You get an object that looks like this:

{
  'id1': { id: 'id1', ... },
  'id2': { id: 'id2', ... },
  'id3': { id: 'id3', ... },
}

If you want to group all objects in an array by a specific property, you can do something very similar:

const obj = arr.reduce((prev, next) => {
  // Grab the property from the item that we want to group by
  const { prop } = next;

  // Add a new array to the object if this is the first one
  // with this value
  if (prev[prop] === undefined) {
    prev[prop] = [];
  }

  // Add our item to this array
  prev[prop].push(next);

  // Return the object so we can add more items
  return prev;
}, {});

Our final object looks like this:

{
  'prop1': [
    { prop: 'prop1', ... },
    { prop: 'prop1', ... },
    { prop: 'prop1', ... },
  ],
  'prop2': [
    { prop: 'prop2', ... },
    { prop: 'prop2', ... },
    { prop: 'prop2', ... },
  ],
}

🔗 (Sponsored) Keep on top of new tech with DevTrends.io

It seems that every week there's a new JS framework, or a new and better way to write CSS (which is just the old way again).

Just as you get comfortable writing unit tests you learn that integration tests are actually the way to go. Oh, and the way you've been writing your tests is completely wrong.

Ugh 🤦‍♂️

It would be so much simpler if we could ignore everything, but hidden among all these new tools are amazing gems that can transform the way we work.

But keeping up with all of them is impossible.

That's why my long time friend, Anthony Gore (who also created Vue.js Developers), created DevTrends.io

He does all of the research on new tech and tools for you, and then teaches you the most important details in short, informative videos.

Click here to check out some recent videos

📜 Vuex — but for React

This is an interesting short read on writing a Vuex clone, but in React.

I've taken lots of ideas from React and used them in Vue over the years, but haven't seen many people take ideas from the Vue ecosystem yet.

What patterns or ideas can you borrow from other frameworks or languages you've used in the past?

Read it here: I wrote Vuex — but for React!

🗞 News: It's conference season!

Yes, I'm just copying and pasting this section each week.

But you know what? I don't want you to forget about a great conference — like Nuxt Nation, which is happening next week.

We have four incredible conferences coming up in the next 2 months, all accessible online and two offering (limited) in-person experiences:

Nuxt Nation — September 15th — free and online
Vuejs Global (Amsterdam) — October 1st and 4th — Amsterdam and online
Vue.js Conference (London) — October 20-21 — London and online
VueConf Toronto — November 22-23 — free + online

💬 Comments

"Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?'" — Steve McConnell

🧠 Spaced-repetition: Define multiple components in a single file

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

Every now and then you just need a small component, one that's not worth an entirely new file:

// A small, secondary component
const SmallComponent = {
  // Create a component like you normally would
  data() {
    //...
  },
  computedProps: {
    //...
  },

  // Use the template property instead of a template block
  template: `
    <div>Hello!</div>
  `
};

// Your main component
export default {
  components: { SmallComponent },
  // ...
};

This is perfect for reusing code within a component, where a v-for doesn't work.

However, if the code is more complex or is likely to be used by other components, making a proper reusable component is the best way to go.

Note: You can get proper syntax highlighting of the HTML string using this VSCode extension.

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #24: Mastering Computed Props

Michael Thiessen — Thu, 02 Sep 2021 12:16:55 +0000

This newsletter was sent out to my list on September 1, 2021. Sign up here to get emails like this each week!

They say, "the more the merrier", and I like to be merry*, so here are some more tips.

* I'm sure you enjoy merriment as well.

* Also, not the hobbit.

— Michael

🔥 Master computed props

When a function does more than just return a value, it makes your code more complicated.

These are called side effects, and you should never have them inside of a computed prop:

export default {
  computed: {
    fullName() {
      this.fetchUserInformation();  // Side effect
      return `${this.firstName} ${this.lastName}`;
    },
  },
};

However, fixing this is quite straightforward. We can just move that side effect into a watcher that is triggered whenever the computed prop updates:

export default {
  computed: {
    fullName() {
      return `${this.firstName} ${this.lastName}`;
    },
  },

  watch: {
    fullName() {
      this.fetchUserInformation();  // Side effect
    },
  },
};

This applies equally to the composition API, although the syntax is slightly different.

At first glance, this may seem like we made the code more complicated. But actually, we've made it a lot simpler.

This concept is expanded on in my course, Clean Components.

🔥 The picture element

The <picture> element lets us provide many image options for the browser, which will then decide what the best choice is:

<picture>
  <!-- You can have as many source tags as you want -->
  <!-- (or none at all!) -->
  <source srcset="big-image.png" media="(min-width: 1024px)">
  <source srcset="bigger-image.png" media="(min-width: 1440px)">
  <source srcset="biggest-image.png" media="(min-width: 2048px)">

  <!-- One img tag is required to actually display the image -->
  <!-- and is used as the default choice -->
  <img src="regular-image.png">
</picture>

You can provide different options based on screen size, resolution, and supported image formats.

The mdn docs have a lot more info on this element.

🔗 (Sponsored) Keep on top of new tech with DevTrends.io

It seems that every week there's a new JS framework, or a new and better way to write CSS (which is just the old way again).

Just as you get comfortable writing unit tests you learn that integration tests are actually the way to go. Oh, and the way you've been writing your tests is completely wrong.

Ugh 🤦‍♂️

It would be so much simpler if we could ignore everything, but hidden among all these new tools are amazing gems that can transform the way we work.

But keeping up with all of them is impossible.

That's why my long time friend, Anthony Gore (who also created Vue.js Developers), created DevTrends.io

He does all of the research on new tech and tools for you, and then teaches you the most important details in short, informative videos.

Click here to check out some recent videos

📜 Using Composables Well

React has hooks, Vue has composables. It's a term you maybe haven't heard before, but composables are the functions built using the composition API.

It's not an "official" term, but most of the community has settled on using this term. This is how open source works, right?

In this article, Markus goes through some common patterns for building composables with the composition API.

Read it here: Vue Composition API: Composables

🗞 News: 2 weeks until Nuxt Nation

We have four incredible conferences coming up in the next 3 months, all accessible online and two offering (limited) in-person experiences:

Nuxt Nation — September 15th — free and online
Vuejs Global (Amsterdam) — October 1st and 4th — Amsterdam and online
Vue.js Conference (London) — October 20-21 — London and online
VueConf Toronto — November 22-23 — free + online

💬 90%

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." — Tom Cargill

🧠 Spaced-repetition: Shorthand for named slots

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

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.

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.

🔥 Vue Tips #23: Why there must be one source of truth

Michael Thiessen — Tue, 31 Aug 2021 12:16:59 +0000

This newsletter was sent out to my list on August 25, 2021. Sign up here to get emails like this each week!

Heyo,

I've got some more tips, an article, and a quote — as always.

If you know someone who would enjoy these tips, forward this email to them or send them here so they can sign themselves up.

The more people that sign up, the more I feel obligated to pack in tons of value, and that's especially good for you, right?

So share this newsletter with others, even if it's just for purely selfish reasons 😏

— Michael

🔥 Why there must be one source of truth

This is the most important principle of state management that I know:

Each piece of state has a single owner, a single source of truth.

No one else is allowed to modify the state. It's just borrowed temporarily.

If you have an array in a Vuex store, only that Vuex store can update it. Anywhere in your app that needs that value must get it from the store (whether directly or through another component).

If the state is owned by a component, only that component can modify it. This means other comopnents must emit an event to that component, which can then decide what it wants to do.

Why?

If you allow state to be modified from anywhere, your code becomes a tangled mess.

With a single source of truth, you can easily understand what's happening.

The best code is easily understood.

🔥 Aria roles you didn't know you needed

Aria roles are used to tell a screenreader what an element is for.

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:

Widget - roles like button, checkbox, separator, tab, or scrollbar
Composite - roles like combobox and listbox (these are for dropdown menus), radiogroup, or tree
Document structure - this includes article, presentation, figure, feed, and directory
Landmark - banner, main, navigation, and region are roles in this category
Live region - alert, log, marquee, and status are roles that might update with real-time information
Window - alertdialog and dialog are the only two roles in this category

You can check out the full list here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques#roles

📜 (Sponsored) HarperDB, the best db for frontend devs

...but it's not exactly a database.

For me, the most frustrating part of building an app is all of the backend stuff.

You need to find somewhere to persist the data, another place to put the API, and then spend hours configuring and setting it all up. If you pick the one that's easy to use, your project will outgrow it. But if you go all-in with AWS you never even get the project off the ground 🤦‍♂️.

HarperDB does all of this stuff for you, in an easy-to-use package that grows with your project. Here are its best features:

NoSQL and SQL hybrid
Custom API functions (powered by Fastify)
Simple REST API to access everything
Really easy to use admin dashboard to create tables, add or delete data

I've only played around with HarperDB a bit, but so far I'm impressed, and I plan to use it on my next project.

The best way to get started is through the HarperDB docs, but they also have a well-documented API.

There's also this demo in React. There's nothing yet for Vue + HarperDB, but that just means you could be the one to build it!

📜 The Dark Side of Nuxt

Nuxt is a fantastic framework, but even the best frameworks aren't perfect.

It this article, Jonas uses his experience as a consultant to explore the dark side of Nuxt, and how to refactor the Nuxt Hacker News clone to use Fastify and Vite to eliminate some of those dark spots.

Read it here: Rewriting Nuxt HN with Fastify, Vite and Vue 3

🗞 News: It's (still) conference season!

If you didn't get the memo last week, we have four incredible conferences coming up in the next 3 months, all accessible online and two offering (limited) in-person experiences:

Nuxt Nation — September 15th — free and online
Vuejs Global (Amsterdam) — October 1st and 4th — Amsterdam and online
Vue.js Conference (London) — October 20-21 — London and online
VueConf Toronto — November 22-23 — free + online

💬 Simplicity

"Complicated code is a sign that you don't understand your program well enough to make it simple." — Steve McConnell

🧠 Spaced-repetition: Clean up your Tailwind classes

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

After using Tailwind for awhile you'll start to notice you end up with a lot of elements that have tons of classes on them:

<div class="mx-5 w-1/2 md:mx-0 md:w-auto mb-8 flex justify-end">

You can combine all of these utility classes together into a single class by using the @apply directive:

<template>
  <div class="combined"></div>
  <div class="combined"></div>
</template>

<style>
.combined {
  @apply mx-5 w-1/2 md:mx-0 md:w-auto mb-8 flex justify-end;
}
</style>

This lets you reuse those styles without having to create a whole new Vue component for them.

Of course, one of the best parts of Vue is that we can create reusable components, but not everything needs to be (or deserves to be) it's own component.

Exclusive tips and insights every week

Join 8135 other Vue devs and get exclusive tips and insights like these delivered straight to your inbox, every week.