DEV Community

Cover image for Good practices and Design Patterns for Vue Composables

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...
Collapse
 
arfedulov profile image
Artem Fedulov

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.

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

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

Collapse
 
asedas profile image
asedas • 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 }
}
Enter fullscreen mode Exit fullscreen mode

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?

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

Very good recommendation, thanks for sharing!

Collapse
 
asedas profile image
asedas

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

Collapse
 
mahmoudabdulmuty profile image
Mahmoud Abdulmuty

"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! 😊"

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

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

Collapse
 
franciskisiara profile image
Kisiara Francis

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.

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

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

Collapse
 
mannu profile image
Mannu

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

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

Heyo,

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

Collapse
 
marcelorafaelfeil profile image
Marcelo Rafael • 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 };
}
Enter fullscreen mode Exit fullscreen mode

What do you think about this approach?

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

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

Collapse
 
lorenaramonda profile image
Lorena Ramonda

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?

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski

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! :)

Collapse
 
merline profile image
merline

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