DEV Community

Good practices and Design Patterns for Vue Composables

Jakub Andrzejewski on June 19, 2023

I recently had a great discussion with my team at Vue Storefront about patterns for writing Vue composables. In the case of our system, composables...

Read full post

asedas • Aug 30 • Edited

Hi @jacobandrewsky, good article. I'm Vue/Nuxt developer quite long time, but I found that in most advanced cases those patterns are not enough and I miss one thing here. Especially when you share composable across multiple components (for code reusability ofc), it turns out that often definition and declarations of variables/functions are inside useComposable() function, not exported outside it. Like in example (it's trivial but you will get the point):

// this function should be outside of exported function useMouse()
function update(event) {
  x.value = event.pageX
  y.value = event.pageY
}

export function useMouse() {
  // depends on the usecase those refs could be also moved out
  const x = ref(0)
  const y = ref(0)

  onMounted(() => window.addEventListener('mousemove', update))
  onUnmounted(() => window.removeEventListener('mousemove', update))

  return { x, y }
}

why is that? because each time we use composable, it runs whole function - so allocates memory for declared functions/variables inside and computes values for declarations, etc. By moving them outside composable function scope we make them reusable across all invokes of composable function which makes this a bit more memory optimized and faster. Ofc not everything can be externalized, but in most projects I've used composables there were quite lot such stuff which in general makes a difference in total. What do you think about such pattern?

Jakub Andrzejewski • Sep 9

Very good recommendation, thanks for sharing!

Aleksandr Lukianchikov • Dec 16

Good idea =)

we save resources
we separate stateful and stateless logic
forces us to use of pure functions

asedas • Aug 31

One update: I know about possible closure memory leak due to this externalization but I'm talking about case where we do this intentionally.

Artem Fedulov • Jun 20 '23

Hi! Good problem you've touched in this post. I've been trying to find a proper way of writing composables for a year or two. So far i came to a conclusion that when we work with a global app state, it's better to use some state management library (e.g. pinia). To me composables are functions that create instances with internal state. There are might be a lot of instances of the same composable and that's fine until these instances start affecting some global state (e.g. useState in Nuxt). So when we start touching global state in a composable, it's probably time to use a state management library. So, shortly speaking, composables are for non-singleton instances, and state manager is for singleton instances. This is just my approach to composables. For sure there are different approaches.

Jakub Andrzejewski • Jun 21 '23

Hey Artem,

Thanks for this comment. I think that you can use composables for global state, but as you mentioned, there are already very good solutions like Pinia that will allow you to probably work with global state in a better way :)

Mahmoud Abdulmuty • Jun 22 '23

"Hi Jakob! Thanks for sharing this informative post about Vue Composables. I found it really helpful! 🙌

I have a question regarding the difference between using vue-composable and Pinia. Could you please shed some light on how these two libraries vary in terms of their primary purposes and functionalities? I'm trying to understand which one would be a better fit for my Vue.js projects.

Thanks in advance, and keep up the great work! 😊"

Jakub Andrzejewski • Jun 22 '23

Hey hey!

I am glad that you liked the article. I have not used the vue-composable yet but I have used both Pinia and normal Vue Composables so I can compare them.

In the past, I was using Vuex a lot (the ancestor of Pinia) but with the introduction of Composables, you can manage global state there easily. I dont use Pinia anymore as everything I needed I can do right now with a composable. I just need to register a ref before the composable and then create some sort of getter so that the value can be easily accessible from anywhere around.

But maybe someone else will be able to share more light on this vue-composable package :)

Kisiara Francis • Oct 6 '23

In both examples from the Vue documentation, it is clear that the core team has named their files mouse.js and fetch.js respectively. But you suggest that filenames be prefixed with 'use' and then follow a camelCase naming convention. Why so? Why not stick to the example provided, after all the function name itself already describes the contract.

Jakub Andrzejewski • Oct 6 '23

Hey, good question!

This is something that me and my team come up with.

It is easier for us to search for a file named useComposable than to search through the whole project for the query useComposable. Why? Because you may have several occurences of this composable in your app while you will have only one file.

Also, Nuxt framework uses this approach for naming files nuxt.com/docs/guide/directory-stru...

This rule is more like a matter of preference. This is what worked for me and my team but does not have to necessarily work for you the same way. It is a recommendation rather than strict rule :)

Mannu • Jun 22 '23

I am thinking of learning vue. what do u guys say

Jakub Andrzejewski • Jun 22 '23

Heyo,

I would recommend to do that. It is a great piece of code that allows you to write efficient applications very easily!

Marcelo Rafael • Sep 3 • Edited

Good article, thanks for that.
I have a question, maybe you can help me with your opinion.
If I would like to execute some action right after I include a product into the cart, what do you suggest?

I thought to write a function into the composable named as onAdd that will receive another function that will be called after a product be included into the cart. i.e:

export const useCart = () => {
  const cart = [];
  let onAddCartCallback = undefined;

  const addProduct = () => {
    /* ... */
    if (onAddCartCallback) {
      onAddCartCallback();
    }
  }

  const onAdd = (callback) => {
    onAddCartCallback = callback;
  }

  return { cart, addProduct, onAdd };
}

What do you think about this approach?

Jakub Andrzejewski • Sep 9

I would recommend maybe adding a watcher over the cart element. Once cart changes (for example becomes truthy) let's automatically call another function (i.e. display notification). This way, you would trigger this function everytime the cart will be updated and you wouldn't need to do it in other places :)

Lorena Ramonda • May 6

Hello @jacobandrewsky there's a thing that it's a little confusing to me.
In the paragraph called Composables contract you say:

Composable file names should start with use for example useSomeAmazingFeature.ts

but then in example right above you write:

import { useFetch } from './fetch.js'

Wouldn't it be better to reflect in the example the rules that you are suggesting to avoid misunderstanding? 😁

Or were you meaning something else?

Jakub Andrzejewski • May 8

Heyo, good catch!

That is indeed correct. I think I have copied the useFetch example from the official documentation.

Will fix that in a sec! :)

merline • Jan 30

Great read on Vue Composables! The article outlines essential practices and design patterns for efficient Vue development. Speaking of seamless transitions, I highly recommend checking out Day-to-Night by homery.design/services/day-to-night/. Their service brilliantly aligns with Vue's flexibility, offering a smooth day-to-night transition solution. It's a valuable addition to consider for enhancing user experience and design aesthetics. #VueJS #WebDevelopment #DesignPatterns