Maybe it's because I'm so comfortable with it, but I really like the Vue.js 2 way of doing things. It forces developers to be organized. And yeah, I know that's what turns a lot of devs off of Vue 2. But it's what I like about it.
same, the OptionsAPI gives you a structure, Composition API can be written like PHP a.k.a garbage. Its up to the developer to keep it clean. That part sucks.
I have seen some react components that I literally couldnt make sense of because of this composition api approach. Yes Options api wasnt all that but I too loved the organization to an extent and the easy reactivity, i hate having to do .value on a property to get a value now.
I got into vusejs because the options api seemed less complex than react. Now having built a number of applications with react, the composition api in vuejs makes me just want to develop using react.
Composition API in my opinion feels clean and natural. I much prefer it compared to Options. In the end it is up to you which one you are more comfortable with.
Don't know if anybody else pointed this out already, but using the hybrid approach you can actually access the refs and functions returned by the setup method in your options API code just fine by using "this".
Having worked with both Options API and Composition API, I have fallen in love with Composition API with script setup. Using it with TS, and JS is ❤ again! 😊
The only thing I do miss going from the Options API to Composition is inheritance. I miss being able to "classically" extend a component to a child component, and I've never been a fan of composing my extensions. The ability to extend components like that was the main reason I went from React to Vue, and the Composition API in Vue seems like it's trying to follow React's paradigm. Granted, Vue's Composition API is far less hacky than React's Hooks API, but it still feels like Vue is just trying to be more like React for the sake of being more like React. One thing you left out -- Pinia primarily works with the Composition API (specifically the setup() function). It'll work with the Options API, but integration is much simpler with setup(). At least, it was for me. So, if you're planning to use Vuex's replacement or start a Nuxt 3 project, it's likely you're better off going the Composition route.
After fiddling for a bit with TS+ESLint with the Options API I came to the conclusion that this particular config is unusable (lots of false positives involving `this` keyword being undefined) I went head on for Composition API and never looked back.
This was really helpful, since I'm somewhat a beginner with Vue and didn't get the full meaning of the APIs. Maybe you want to do an (even) shorter video stating just the basics and maybe referring to this one. I could imagine people watching it just to get the APIs.
Could you explain how to build and more importantly test services using composition API? Would you even put business logic in composable "services" in a non trivial prod app?
Composition API: When multiple components need the same ancestor data, or when a deeply nested component needs ancestor data Options API: When a child component needs parent data
@@doublemarvellous5525 You can still use Options API. There was 1 (one) change. Then they made it so that you could remove some boilerplate code. I don't know what you're so annoyed about.
Options API has always been more readable but YOU MISS ONE BIG ASSET of the composition API imho: you expose only what you need to the template, hence not polluting it with your intermediate computed (since VueJS Guidelines tells us to make as many atomic computed properties as possible). Thoughts?
Nice videos ! Very helpful to refactor my projects :) I’ve seen that you were offering mentoring before is it still a thing ? Cause I would be very interested
I really love the script setup syntax: it's verbose, but explicit. All the magic Vue does in background with the Option API is gone. There's only one issue I'm trying to solve, with Volar and the strong typing of components; how to chain $attrs but keep Volar happy with the typings: how to declare that I want to chain a Prop or Event without redeclaring it multiple times.
Yes, but. The mantainer of the vue-class-component package that brings typescript decorators to Vue has not been maintaning it, so much so that Quasar already put a deprecation notice and recommends the Composition API instead. I need to catch up, maybe for non-Quasar pure Vue apps we can still use it. I really love class-based components.
What works best for me especially when we're a team of ten plus developers is writing class based components. Typescript + Vue-property-decorator + Vue.js 3 has been nothing but a delight for us. The backend developers love to work on the front end too!
We use vue-class-component (on which vue-property-decorator is based). Works great, looks great, but it is not supported by Volar or Vetur, which is a serious disadvantage.
@@hansadmiraal I can see you having issues with Vetur. We've resorted to writing our own snippets and configuring vetur to match class based components. Hope that helps!
After React hooks, Vue does not seem better than React. I think Vue didn't need to evolve into V3. V2 was just perfect. They should've just added TS to V2
DOM implementation has been completely rewritten in Vue 3 (using latest JS/TS and browser features), which leads to major performance improvements (55% faster, memory usage is down to 54%, updates up to 133%). Build time and size are also significantly improved.
A: Vue composition API, composables, script setup, css v-bind, full TS support, increased performance and modularity. These are all incredibly good reasons to evolve into V3. Fact is that V2 was not perfect and V3 is a massive improvment. Also, B: Vue composables are way better than React hooks and im tired of pretending they are not
In my experience., if your creating child component and u want to access its functions or variable using ref, dont use script setup,, use setup() function or the options API... for setup() function, u can only access variables/functions that are returned.
With vue 3 and the script setup approach template refs and reactive refs are kinda merged in the same logique so even in the script setup you can actually access in a very clean fashion to the children components and it’s functions or attributes (also don’t forget to use defineExpose to make functions and attributes available in your child components) ^^
"In my experience" Didn't you know, in your experience, that exposes stand-alone functions to define props, emits, and provide data to child components?
![Vue 3 Composition API Introduction [FULL TUTORIAL]](/img/n.gif)
👉 Sign up and get free Vue cheat sheets and updates!
www.vuecourse.tech/
Maybe it's because I'm so comfortable with it, but I really like the Vue.js 2 way of doing things. It forces developers to be organized. And yeah, I know that's what turns a lot of devs off of Vue 2. But it's what I like about it.
same, the OptionsAPI gives you a structure, Composition API can be written like PHP a.k.a garbage. Its up to the developer to keep it clean. That part sucks.
I have seen some react components that I literally couldnt make sense of because of this composition api approach. Yes Options api wasnt all that but I too loved the organization to an extent and the easy reactivity, i hate having to do .value on a property to get a value now.
Always options api easy organised and the very reason why i fell in love with vue,
I got into vusejs because the options api seemed less complex than react. Now having built a number of applications with react, the composition api in vuejs makes me just want to develop using react.
As someome relatively new to Vue, the options API feels more approachable and intuitive to use. And more organised.
I can see that. Composition API is not for everyone.
I am the "jack of all trades" guy in our tech. I really don't have time to dive deep. Thus, options API feels more intuitive and pragmatic to me.
Composition API in my opinion feels clean and natural. I much prefer it compared to Options. In the end it is up to you which one you are more comfortable with.
Don't know if anybody else pointed this out already, but using the hybrid approach you can actually access the refs and functions returned by the setup method in your options API code just fine by using "this".
Having worked with both Options API and Composition API, I have fallen in love with Composition API with script setup. Using it with TS, and JS is ❤ again! 😊
The only thing I do miss going from the Options API to Composition is inheritance. I miss being able to "classically" extend a component to a child component, and I've never been a fan of composing my extensions. The ability to extend components like that was the main reason I went from React to Vue, and the Composition API in Vue seems like it's trying to follow React's paradigm. Granted, Vue's Composition API is far less hacky than React's Hooks API, but it still feels like Vue is just trying to be more like React for the sake of being more like React.
One thing you left out -- Pinia primarily works with the Composition API (specifically the setup() function). It'll work with the Options API, but integration is much simpler with setup(). At least, it was for me. So, if you're planning to use Vuex's replacement or start a Nuxt 3 project, it's likely you're better off going the Composition route.
I am using pinia with options API, just follow the vue2 docs (while using vue3 in the project) and everything worked fine.
@@Forshen I didn't say it couldn't be done or that it was difficult, but Pinia is so dead simple to work with if you're using the Composition API.
After fiddling for a bit with TS+ESLint with the Options API I came to the conclusion that this particular config is unusable (lots of false positives involving `this` keyword being undefined) I went head on for Composition API and never looked back.
Agreed, had same experience with options API. With composition API, vue's DX have improved significantly and now on par with other popular frameworks.
It does take a bit of configuration.
This was really helpful, since I'm somewhat a beginner with Vue and didn't get the full meaning of the APIs. Maybe you want to do an (even) shorter video stating just the basics and maybe referring to this one. I could imagine people watching it just to get the APIs.
Could you explain how to build and more importantly test services using composition API? Would you even put business logic in composable "services" in a non trivial prod app?
What theme do u use for vscode?
Dude, what theme are you using? Love it..
Composition API: When multiple components need the same ancestor data, or when a deeply nested component needs ancestor data
Options API: When a child component needs parent data
Lmao
Composition API's context: Don't we have statement management for that?
Too many ways to do the same thing. This will really mess up the ecosystem
This is what drives me crazy. As soon as you learn something it has become the passe way to do it.
@@doublemarvellous5525 welcome to the dev jog !! 😅
I don't think it will, actually I think it has already done it..
unopinionated frameworks
@@doublemarvellous5525 You can still use Options API. There was 1 (one) change. Then they made it so that you could remove some boilerplate code. I don't know what you're so annoyed about.
Can we get a video on fetching with nuxt 3?
What about #5 - JSX like approach and #6 - render functions?
I only use render functions on component libraries
what plugin do you use to get certain keywords to glow in this neon style?
SynthWave '84
What the heck, how do you get glowing syntax?? That color scheme is awesome
Honestly, just for the TS support the composition API is worth it.
Options API has always been more readable but YOU MISS ONE BIG ASSET of the composition API imho: you expose only what you need to the template, hence not polluting it with your intermediate computed (since VueJS Guidelines tells us to make as many atomic computed properties as possible). Thoughts?
Good video still, keep it up!
what is code editor theme name?
Nice videos ! Very helpful to refactor my projects :) I’ve seen that you were offering mentoring before is it still a thing ? Cause I would be very interested
keep going with Vue3 content. Nuxt3 would be awesome too
finally....! thanks for saying this... i was so sick of people saying composition api is going to "replace" options api...
thank you for this awesome video ❤
This video doesn’t talk about why we don’t need the composition API, it actually recommends it. The title is wrong.
Well, I think either one will work, but I really do like the options API>
Web3 with Vue would be amazing!
Cool, I'll be looking into it soon!
I really love the script setup syntax: it's verbose, but explicit. All the magic Vue does in background with the Option API is gone.
There's only one issue I'm trying to solve, with Volar and the strong typing of components; how to chain $attrs but keep Volar happy with the typings: how to declare that I want to chain a Prop or Event without redeclaring it multiple times.
I do not see return object in Setup API #3
web 3 ? YEAH ABSOLUTELY!!...a solana app would be awesome!
Thank you. It's very useful for me
Options API is organized and I believe that's more important
Can you still use TypeScript class syntax with Vue 3?
It should work
Yes, but. The mantainer of the vue-class-component package that brings typescript decorators to Vue has not been maintaning it, so much so that Quasar already put a deprecation notice and recommends the Composition API instead.
I need to catch up, maybe for non-Quasar pure Vue apps we can still use it. I really love class-based components.
What works best for me especially when we're a team of ten plus developers is writing class based components. Typescript + Vue-property-decorator + Vue.js 3 has been nothing but a delight for us. The backend developers love to work on the front end too!
We use vue-class-component (on which vue-property-decorator is based). Works great, looks great, but it is not supported by Volar or Vetur, which is a serious disadvantage.
@@hansadmiraal I can see you having issues with Vetur. We've resorted to writing our own snippets and configuring vetur to match class based components. Hope that helps!
6:25 t-i-h-i-s 😂
After React hooks, Vue does not seem better than React. I think Vue didn't need to evolve into V3. V2 was just perfect. They should've just added TS to V2
It's completely impossible to give 100% TS support in options API if you know how mixins work in vue.
DOM implementation has been completely rewritten in Vue 3 (using latest JS/TS and browser features), which leads to major performance improvements (55% faster, memory usage is down to 54%, updates up to 133%). Build time and size are also significantly improved.
A: Vue composition API, composables, script setup, css v-bind, full TS support, increased performance and modularity. These are all incredibly good reasons to evolve into V3. Fact is that V2 was not perfect and V3 is a massive improvment.
Also, B: Vue composables are way better than React hooks and im tired of pretending they are not
If you still use Redux there is no point of Hooks Vue3 composition Api with composables is lit
Web3 web3 web3 !!
In my experience., if your creating child component and u want to access its functions or variable using ref, dont use script setup,, use setup() function or the options API... for setup() function, u can only access variables/functions that are returned.
interesting.
With vue 3 and the script setup approach template refs and reactive refs are kinda merged in the same logique so even in the script setup you can actually access in a very clean fashion to the children components and it’s functions or attributes (also don’t forget to use defineExpose to make functions and attributes available in your child components) ^^
You have to use defineExpose to access properties declared in a script setup.
"In my experience"
Didn't you know, in your experience, that exposes stand-alone functions to define props, emits, and provide data to child components?
There are 5 ways to run Vue ......... what we need is a new way to rule them all and unify! .................. there are now 6 ways to run Vue ......
There are 0 reasons to use OptionsAPI.
Options API gets very ugly when you lots of large components, I personally prefer Composition API
Erick, don't put this title, composition API it's the way to go. Errrrr....