Note: it's all changed in Vue 3.4: "a substantial refactor of the reactivity system, with the goal of improving re-compute efficiency of computed properties". "With the post-3.4 optimizations, the callback now only fires if the computed result has actually changed."
Since vue 3 i struggle when to use composable and when not. Like everything could be outsourced in a composable (every api request, every state change etc.). It is very confusing... 🤕 Like 80% my logic is in composables... Is there any tip or video that could help?
When the logic is reused, that's when I try to wrap things in a composable. I've also seen it used as a way to just structure code so SFCs aren't massive.
@@LearnVue We use it in our company in both mentioned ways. For example, we have different modules in our web app. If we have shared state between the modules, we move it into a composable with global state. If we have module or even SFC specific logic and state, then we still move it into a composable with local state (not shared, newly created whenever the useX is called). As @LearnVue pointed out, this is also a great way to reduce SFC size. By that, our SFCs stay much more readable, since we move it's core logic behind an interface (the composable).
@@butbutmybutt Oh yeah, it's a nice little abstraction I guess. I don't know that it adds much imo, watch and watchEffect aren't exactly overly complex or verbose! If you're using it a lot then it could make sense.
lol the title was too good to pass up. i think the use case is 3:46 where you have an expensive operation that relies on a simple computed property is the main summary from a title -> answer perspective. the default use and optimizations for computed is still good to handle a majority of use cases, but at least for me - learning about eager computed taught me a lot about the specifics of how vue computed caches and updates.
Note: it's all changed in Vue 3.4: "a substantial refactor of the reactivity system, with the goal of improving re-compute efficiency of computed properties". "With the post-3.4 optimizations, the callback now only fires if the computed result has actually changed."
Since vue 3 i struggle when to use composable and when not.
Like everything could be outsourced in a composable (every api request, every state change etc.).
It is very confusing... 🤕
Like 80% my logic is in composables...
Is there any tip or video that could help?
did you have so much logic reuse to transfer all those codes into composables?
When the logic is reused, that's when I try to wrap things in a composable.
I've also seen it used as a way to just structure code so SFCs aren't massive.
@@LearnVue We use it in our company in both mentioned ways. For example, we have different modules in our web app. If we have shared state between the modules, we move it into a composable with global state. If we have module or even SFC specific logic and state, then we still move it into a composable with local state (not shared, newly created whenever the useX is called). As @LearnVue pointed out, this is also a great way to reduce SFC size. By that, our SFCs stay much more readable, since we move it's core logic behind an interface (the composable).
I think the real issue you highlighted is unnecessarily using a computed value as a dependency on another computed value!
yes, just use watch functions. but I think it's cleaner with eagerComputed, less code.
@@butbutmybutt Oh yeah, it's a nice little abstraction I guess. I don't know that it adds much imo, watch and watchEffect aren't exactly overly complex or verbose! If you're using it a lot then it could make sense.
Great Summary!
couldn’t have done it without a great original blog post and reactivity library 😉
Could you share the Theme name, please? Looks really nice.
Thank you for this valuable information
thank you for sharing all the great stuff!
Very helpful
didn't know about this. useful
i thought it was neat too when i read the article - glad you agree :)
This is great, thank you!
Very nice. Thank you.
very interesting!
Thanks
Thanks 💛💙
Thanks for sharing!
Thanks for watching!
"When You SHOULDN'T Use Computed in Vue" - "In a few cases"
The title is a better clickbait like that 😆
@@jhblack23 not click bait, he provides very little reason not to use it
lol the title was too good to pass up.
i think the use case is 3:46 where you have an expensive operation that relies on a simple computed property is the main summary from a title -> answer perspective.
the default use and optimizations for computed is still good to handle a majority of use cases, but at least for me - learning about eager computed taught me a lot about the specifics of how vue computed caches and updates.
GOD!!!My broo
Interesting 🐱
I think so too!
This is outdated. Can't replicate it on Vue 3.5
Yeah this is actually the default on 3.4+ blog.vuejs.org/posts/vue-3-4#more-efficient-reactivity-system
just do $: expensiveCalculation(count) and you will be good
keep calm and use svelte