Very important topic, looking to see more content on that. Looking on how people use composition api in big enterprise projects I see a lot of issues with understanding the fundamentals which causes a lot of problems such as: - Tight coupling of composables between each other: people try to call a composable inside composable which doesn't allow proper tree shaking - Placing to much stuff inside a composable - many times people just detach all domain logic from components, creating one mega composable that just floats in space similar to Vuex store which causes memory leaks and makes overall application more complex to understand - Trying to use reactivity for everything - for some reason people just thinking that reactivity is free of charge and converts objects with tenths of thousands properties received from a server straight into reactive function, which leads to huge issues with performance. Summarizing all of the above I think it would be great to talk about how to "not write composables" or a list of do's and don'ts
Hello! You can find a written tutorial series on Composables in our blog here: www.vuemastery.com/blog/coding-better-composables-1-of-5 I just linked you to Part 1, but Parts 2-5 are also available there. 😁
One thing to avoid would be using "options" as a param for the composition APIs that you build. This forces the user dev of the API to have to go read the code to figure out what the options are, and in the case of your third example would force them to go down a rabbit hole of reading API implementations that the API they are trying to call is using. For writing APIs in any language / framework it's best to expose what all possible args are and in JS can be done by: function myFunc({arg1, arg2}) {...} This allows the caller of myFunc to quickly see what the param options are and pass them along in a single object, most IDEs will show this as a hint when using the function, so you won't even have to go and find where the API is defined.
I have a question, are there any difference between This one: myValue ?? defaultValue and This one: myValue || defaultValue In both cases, it will return the firt truly value found, so, why does exists '??' operator in js?
"myValue ?? defaultValue" returns the first value that is not explicitly null or undefined, meaning it will return the first defined value, including an empty string, 0, true or false. Let's say you want the "defaultValue" set to the boolean "true", but you want to be able to pass the boolean "false" as "myValue". Using "myValue ?? defaultValue" will work as intended in that case because "myValue" isn't null or undefined, while "myValue || defaultValue" would always ignore the boolean "false" being sent as "myValue". "myValue || defaultValue" returns the first truthy value, meaning it will skip e.g. undefined, null, false, 0 or empty string. You would only ever be able to pass truthy values as "myValue", or they would always be ignored and "defaultValue" would be used instead. undefined ?? null ?? false ?? true -> returns the boolean "false" undefined ?? null ?? 0 ?? true -> returns the number 0 undefined ?? null ?? "" ?? true -> returns an empty string undefined || null || false || 0 || "" || true -> returns the boolean "true" I might've repeated myself a bit, but I hope that cleared things up.
Wow!! going through such a advanced topic looks like a breeze with amazing instructors :D Again thankyou for such super high quality video (Y) C Cheers
I've been seeing a lot of arguments lately that we should just be using typescript classes in favor of composables - just curious if anyone had some feelings about that.
rly sad that vue is going down the react way, it's a bad way confusing, much boilerplate for nothing i hope they keep the double way updated with all the new features otherwise bb vue and i will move to svelte for fast small projects and angular for big ones
I agree with you it's really boilerplate that allows developers write strange stupid logic instead of business logic and force to think about side effects. Global functions, events and states are always evil especially in junior hands
@@dpv.school1236 well, Vue 3 still supports options API so you can continue using that, composition API is clearly not for beginners, it's just a tool for a very specific use cases, similar to Vuex - you should not put all of your data inside of it. So if you allow yourself to learn with open mind and a grain of common sense - Composition API won't become anything stupid
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
Watch the full Coding Better Composables course here: www.vuemastery.com/courses/coding-better-composables/what-is-a-composable
Very important topic, looking to see more content on that. Looking on how people use composition api in big enterprise projects I see a lot of issues with understanding the fundamentals which causes a lot of problems such as:
- Tight coupling of composables between each other: people try to call a composable inside composable which doesn't allow proper tree shaking
- Placing to much stuff inside a composable - many times people just detach all domain logic from components, creating one mega composable that just floats in space similar to Vuex store which causes memory leaks and makes overall application more complex to understand
- Trying to use reactivity for everything - for some reason people just thinking that reactivity is free of charge and converts objects with tenths of thousands properties received from a server straight into reactive function, which leads to huge issues with performance.
Summarizing all of the above I think it would be great to talk about how to "not write composables" or a list of do's and don'ts
Where can i find this content. It is gonna be very useful to read about it
@@eddieaguilar4878 what content? It was a suggestion/request to Vue Mastery, not something already available int the internet for you to watch
Hello! You can find a written tutorial series on Composables in our blog here: www.vuemastery.com/blog/coding-better-composables-1-of-5
I just linked you to Part 1, but Parts 2-5 are also available there. 😁
One thing to avoid would be using "options" as a param for the composition APIs that you build. This forces the user dev of the API to have to go read the code to figure out what the options are, and in the case of your third example would force them to go down a rabbit hole of reading API implementations that the API they are trying to call is using. For writing APIs in any language / framework it's best to expose what all possible args are and in JS can be done by:
function myFunc({arg1, arg2}) {...}
This allows the caller of myFunc to quickly see what the param options are and pass them along in a single object, most IDEs will show this as a hint when using the function, so you won't even have to go and find where the API is defined.
You can add doc blocks to the function with type definitions.
Love your videos. Sooo pedagogic
Really nice video. Congrats!
amazing but also mindblowing for me 😁
Thank you! Very useful video, wish i can see it everyday
lol what. why can't you?
I wanna ask on 4:09, isnt that way options is required?
How to make it as optional?
Why not use typescript?
Very useful. Thanks! :) 💚
I have a question, are there any difference between
This one: myValue ?? defaultValue
and
This one: myValue || defaultValue
In both cases, it will return the firt truly value found, so, why does exists '??' operator in js?
"myValue ?? defaultValue" returns the first value that is not explicitly null or undefined, meaning it will return the first defined value, including an empty string, 0, true or false. Let's say you want the "defaultValue" set to the boolean "true", but you want to be able to pass the boolean "false" as "myValue". Using "myValue ?? defaultValue" will work as intended in that case because "myValue" isn't null or undefined, while "myValue || defaultValue" would always ignore the boolean "false" being sent as "myValue".
"myValue || defaultValue" returns the first truthy value, meaning it will skip e.g. undefined, null, false, 0 or empty string. You would only ever be able to pass truthy values as "myValue", or they would always be ignored and "defaultValue" would be used instead.
undefined ?? null ?? false ?? true -> returns the boolean "false"
undefined ?? null ?? 0 ?? true -> returns the number 0
undefined ?? null ?? "" ?? true -> returns an empty string
undefined || null || false || 0 || "" || true -> returns the boolean "true"
I might've repeated myself a bit, but I hope that cleared things up.
@@hhh0118 a lot of thanks for explanation! I didn't know that. Now I understand the difference :D
Wow!! going through such a advanced topic looks like a breeze with amazing instructors :D Again thankyou for such super high quality video (Y) C Cheers
I've been seeing a lot of arguments lately that we should just be using typescript classes in favor of composables - just curious if anyone had some feelings about that.
So, basically, it's a utility function?
Isn’t that just a hook?
React name them hooks, Vue name them composables. Yes, same idea
Hooks with super power :)) It can be used out side components, don't need to useCallback, useMemo for optimizing rerender. Anw I love react thought
@@trunghieuhoang3839 I don't want to hear those *useFootGuns* atleast here
Yes, same thing. Very nice addition to Vue.
@@killerdroid99agree
Video: How to build your own custom composable
Also Video: Here's how you install and use our own pre-made composables
More more more
Have you seen our blog series? It's 5 parts and talks all about Composables: www.vuemastery.com/blog/coding-better-composables-1-of-5
I didn't really understand anything you said because you were always explaining JS and TS syntax and only gave a couple of examples.
Maybe you need to learn JS and TS first before watching such videos?
Basically this is a React.js hooks! Why is everything in Vue copy-pasted from React mostly?!?
Svelte or vue?
Why ask in a Vue channel?
Svetle
Nuxt
rly sad that vue is going down the react way, it's a bad way confusing, much boilerplate for nothing i hope they keep the double way updated with all the new features otherwise bb vue and i will move to svelte for fast small projects and angular for big ones
I agree with you it's really boilerplate that allows developers write strange stupid logic instead of business logic and force to think about side effects. Global functions, events and states are always evil especially in junior hands
@@dpv.school1236 well, Vue 3 still supports options API so you can continue using that, composition API is clearly not for beginners, it's just a tool for a very specific use cases, similar to Vuex - you should not put all of your data inside of it. So if you allow yourself to learn with open mind and a grain of common sense - Composition API won't become anything stupid
Bruh it's just a JavaScript function
More more more