Introduction
The release of Vue 3 ushered in a transformational change, moving from the Options API to the Composition API. At the heart...
For further actions, you may consider blocking this person and/or reporting abuse
I like where this article is going, and I have some notes/critiques.
Likes
I like Rule 4.1 as a guideline (object instead of many params); better scalability. I also strongly agree with 9.1 (SRP). It helps scope the work done by the composable (easier maintenance/debugging). 6.2 is another strong agree. 👍
Critiques
Rule 2.1's example is essentially restating 1.1. The only diff was the prefixing "use*", but that doesn't improve comprehension of the composable. Maybe a better example would be (bad)
useDatavs (good)useUserData. The ladder is more descriptive, which is 2.1's point.8.2 is a good guideline (using functional programming core funcs), but the example is too contrived to see the value of the practice.
10.1's example where ref, computed, and functions are grouped can lead to the same problems that Options API did, but maybe the point is to keep composables small/simple enough where that concern is moot.
Comments
Rule 6.2 has no preceding 6.1 (nor does 7 & 8). That's a weird/confusing outline practice and looks accidental.
Also worth noting is 7.2's point on primary & supportive state being read-only. If that's a hard-and-fast goal, computed should be returned instead of ref, which the composable consumer can still change. I'd like to trust devs to follow good convention when they can do what's easier, but experience teaches me to be more pragmatic.
Overall, a good and thoughtful collection of composable conventions!
Thank you for your comments. I did update some points regarding your feedback.
Regarding 8.2, I think the idea of functional programming is worth its own blog post to fully reap the benefits, so I agree with you.
Concerning 10.1, I did refactor a large composable, and grouping the elements helped. Of course, ideally, you shouldn't have a composable that is so large that you need to do this in the first place.
I agree with 7.2. You could use a computed property, but ultimately, the composable itself has to change a primary state somehow. You could have an internal user object and then export the same user as a computed property from the composable. However, I'm not sure if this approach is over-engineered, as I haven't seen this technique used elsewhere. But it's interesting to have immutable states for a composable.
In the end, with this blog post, I aimed to establish some guidelines that could be helpful, as I've noticed that developers often have differing views on composables. I believe there's a need for some kind of guide to unify these perspectives.
Great article!
I think 8.2 could be explained more deeply as functional/imperative is not a basic concept.
I also would love to see some examples that feel a bit more 'real life' and bring out the finer lines between good and bad.. i think the examples chosen are a bit on the obvious side (like the unrelated responsibility is too unrelated.. maybe make it logging in vs getting user data as those are two different things part of the same flow)
A follow up that talks about taking in reactive vs non reactive data and returning reactive data and a best practice structure of how to do that in almost every scenario would also be awesome.
Thank you for your insightful comment!
I agree, section 8.2 could be elaborated further, and more real-world examples would enrich the discussion.
The idea behind this post was to summarise some best practices, but you've highlighted important areas that deserve their own posts. I'm intrigued by your suggestion on a follow-up post regarding reactive versus non-reactive data handling.
Stay tuned for more in-depth explorations in upcoming posts, and thanks again for your valuable feedback!
Art! 👍 I like your blog.
I love how you lay out not just examples but specifically good vs bad examples. Very helpful!
thank you
Also 6.2, you watch here for an error to come from composable.
What if there is more BE calls and more erros may appear in 1 composable? Then if you use the composable in multiple components, it may display the error many times... Any smart solution here?
good question
I wrote a detailed blog post only about Error Handling
you can Check IT Out Here
dev.to/alexanderop/best-practices-...
Why the file should be named with prefix "use"? Vue 3 docs itself is not using this for filenames.
naming is not a hard rule, but your Project should have a better structure
I dont Like how the vue Docs IS doing IT
they have a Mouse.js File which Exports useMouse why not directly useMouse?
when you use vscode and you Type use you directly can than see all your composables