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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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 :)
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):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?
Very good recommendation, thanks for sharing!
One update: I know about possible
closure memory leak
due to this externalization but I'm talking about case where we do this intentionally."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! 😊"
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 :)
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.
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 queryuseComposable
. 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 :)
I am thinking of learning vue. what do u guys say
Heyo,
I would recommend to do that. It is a great piece of code that allows you to write efficient applications very easily!
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:
What do you think about this approach?
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 :)
Hello @jacobandrewsky there's a thing that it's a little confusing to me.
In the paragraph called Composables contract you say:
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?
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! :)
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