Composable Design Patterns in Vue 3

What is a composable?

A composable is a function that returns one or more reactive objects. These might be refs, reactives, computeds or any combination thereof. These functions might also return other functions that allow you to execute actions that affect the reactive objects. They can be as simple or as complex as your application needs.

Convention is that a composable starts with the word use.

Quick example: say you want a ref which has the current time, you could create a composable called useCurrentTime which might look like this:

1import { ref, computed } from "vue";
2
3export function useCurrentTime() {
4	let time = ref(Date.now());
5	const updateTime = () => (time.value = Date.now());
6	setInterval(updateTime, 100);
7
8	const formattedTime = computed(() => {
9		return new Date(time.value).toLocaleString(undefined, {
10			dateStyle: "short",
11			timeStyle: "medium"
12		})
13	});
14
15	return {
16		time,
17		formattedTime
18	}
19}

Now you can import that composable into any component and have yourself a reactive clock:

1<script setup>
2import { useCurrentTime } from "composables/useCurrentTime";
3
4const { time, formattedTime } = useCurrentTime();
5</script>
6
7<template>
8	<h1>The current time is <span v-text="formattedTime"></span></h1>
9</template>

Instance vs Singleton

You may have noticed that a new time ref and a new formattedTime computed are created every single time you call the useCurrentTime composable. So if you call it five times (you really like clocks in your app) then you’ve got five different ref objects running five different interval loops to keep them updated. Obviously this is completely unnecessary, so what can we do?

Our goal is to return the same reactive objects each time the composable is called. This is the Singleton pattern (each call returns the same single instance). To do this, all we have to do is move our reactive objects outside the function scope, like so:

1import { ref, computed } from "vue";
2
3let interval;
4let time = ref(Date.now());
5const updateTime = () => (time.value = Date.now());
6const formattedTime = computed(() => {
7		return new Date(time.value).toLocaleString(undefined, {
8			dateStyle: "short",
9			timeStyle: "medium"
10		})
11	});
12
13export function useCurrentTime() {
14	clearInterval(interval);
15	interval = setInterval(updateTime, 100);
16
17	return {
18		time,
19		formattedTime
20	}
21}

Now both time and formattedTime are declared outside the scope of useCurrentTime and so every call to useCurrentTime will get the exact same reactive objects. We also set up and interval inside the function that only starts updating the time when it’s actually been used somewhere. The call to clearInterval first is to ensure that only one interval loop is running at a time.

Isn't this a store?

Essentially, yes. Composables look very similar to Pinia stores because Pinia stores are themselves composable functions that hew to the Singleton practice.

So why would you choose a composable over a store? Firstly, you might not always want a Singleton. There are many situations that call for different instances of reactive objects. You might, for example, want to track the mouse position over a specific element. You might also want to create a computed value based on whatever string is input:

1import { computed } from "vue";
2
3export function useExclamationPoint(strRef) {
4
5	const withExclamation = computed(() => `${strRef.value}!`);
6
7	return withExclamation;
8}

You might also want to keep your composables from being too tightly coupled with your app since you might want to externalise them into a shared library at some point.

Can't someone else do it?

Surely there must be loads of these composables that lots of projects would need, you might think. You would, of course, be correct. Well done you!

VueUse is a library that houses over a hundred different composables for use in your Vue app. From reactive values for screen dimensions, via VModel proxies, to reactive Bluetooth and Websockets data streams… it truly is an exhaustive collection of battle-tested composables.

Outro

While there are often times where variables are inextricably linked to components and should be left inside the <script> tag of your Vue component, the composable pattern offers you a unique opportunity to extract a lot of your app’s logic into reusable chunks. Got an API search function that you use repeatedly? Composable. Got async data you don’t want to keep hydrating for different components? Composable. Got bagfuls of garden waste just hanging around by your shed? Compostable.

It’s a pattern that contributes to more stable apps since small chunks of logic that do one thing are much easier to unit test than gigantic, monolithic components that act like overworked air traffic controllers.