I actually really like the update! It means you're just using vanilla javascript now and importing the api functions as you would any other library when just writing node. to be honest its kind of amazing to see a framework become less obtrusive as it matures.
I am planning on building a real-world application soon as a tutorial. This will use all the current composition API’s capabilities. Will be good prep for when 3.0 releases.
karl charles Thanks Karl, I truly enjoy it too. Mid-November I’ll start uploading more frequently. Finishing off my degree now, so I don’t have too much time for RUclips.
john m Hi, the Vuex library is still built on the options API, so currently there is no standard way to do this with composition. So whatever hack I come up with will probably be useless. We’ll have to wait for Vuex and Vue3. 👍
Solomon Tsaagane Hi Solomon. Hope you’re doing well and staying safe during this time in Jhb. I use Yarn because of it’s caching strategy and I’ve experienced less fails and faster speeds in general. But it’s not MUCH better and I do use NPM occasionally too. Regards.
Short and to the point. Great videos so far! Any chance you could do a video dealing with Nuxt, nuxt/auth, nuxt/axios, and protected endpoints (passing a JWT in an axios request)? I'm hacking together an application and it works but I don't completely understand it. Cheers!
Hi! At the moment it may seem similar because we’re importing the composition API into our app like we do Vuex (as if it is a plugin), but the API will soon be built into the core. The two are fundamentally different in that Vuex is a state management plugin. You could think of it as pure data that Vue can look at and update it’s own properties based on changes in the store. This API is more central to Vue’s MVVM design pattern. It hooks directly into the View Model. For example - if we add an @click to do some sort of method: We have to dispatch an action from Vue to Vuex to let it know we want to call that method. But with the composition API we can call that method directly on the view model. And that method can directly access data properties on the model, which directly triggers the view to update. The Vuex store doesn’t access our component’s data, we have to explicitly set a computed or data property that links to Vuex state. So basically Vuex is an external plugin to manage application-wide state as a 3rd party. Where the composition API IS the application model and interacts directly with the presentation layer. I hope that makes sense. Very good question!
The Vue composition api looks good and does look a lot better than the old one. But you could just use Vue.extend to share logic what was the problem with that way. In react you make custom hooks and react hooks to share logic. But I’m Vue we are now going to do the same thing but with Vue hooks and regular functions. By the way do you have a good understanding of Vue router I have not found any good cases for the router.beforeEach() method.
VideoVibes Hello! I understand what you mean. Extend still has the problem of grouping code by options instead of logical concerns though. The beforeEach method is something I’ve used in authentication - to add route guards. So I would do something like check if the route is in the list of protected routes and if there is a user in the store; then continue if there is, otherwise redirect to /login. But that’s all I’ve used it for.
I don't see how this is useful :( You _claim_ that the composition API it is more readable... but well, that doesn't do it for me. How about explaining why? You produced several errors in the video - which proves to me that this the new syntax is confusing. That is a pretty high price.. for what benefits? Having stuff somewhere outside in a function or in another file doesn't really make the code automatically better :/
dasten123 Hey. Sorry you feel that way. Luckily it’s not a necessity for everyone to like it or use it. It clicked for me because I remember working on a team where we had a horrible few thousand lines of code in a component. And the jumping up and down from methods to computed to data etc. Was a killer to refactor and understand. Maybe a big component will be a better example, but like I said. It’s not a necessity that you think it’s better or not. So just use the way you enjoy :)
@@KaizenCodes So... would you _only_ use this to refactor/prevent those giant components and for re-usable stuff? Or would you do it for small components like your example as well? Because that is my problem.. People explain it with examples that make the code MUCH harder to understand and everyone is like "ahh, yeah, that makes sense!" And I just don't understand it... it's so frustrating
dasten123 I think it depends really. But I would wait for 3.0 to release first and see what happens - if I happen to work on a production app with/without it. I think if an app/site has no complex logic at all, in any component or view, I’d stick to the options API. But that’s very unlikely in the real-world. If at least one or two components/views have multiple methods and properties - I’d just use the composition API all-round to keep it consistent. Depends on if I’m working in a team too and what their requirements are. You are asking good questions and there is no need to get frustrated - because nobody reasons the same about stuff. It’s like many programming tutorials and guides that have the simple todo app or something like that, it’s not a fair representation of real large apps, but it’s really inefficient to try and explain fundamental concepts in huge videos with many different complexities. Anyway, key point is that I never try to think someone else is wrong, because I am not able to reason like them. (Unless of course something is obviously wrong and everyone agrees). So you may be right, could be that it’s not going to make things better - but from my experience and the time I’ve spent with teams I can reflect on some definite projects that this would have been super helpful in test suites, code reviews and just consistency in general 👍
I have looked into the composition api a bit more and I now like it! The thing that threw me off was that I loved Vue so much for it's simplicity and readability. And when I saw the new api, I thought this was over. Now, I stay by the opinion that the composition-api _is_ confusing, but I realized that some of my larger components I have written with the options-api are confusing and unreadable as well. I guess the love for Vue made me blind :/ I hope to be more open-minded in the future.
![Vue.js Course for Beginners [2021 Tutorial]](http://i.ytimg.com/vi/FXpIoQ_rT_c/mqdefault.jpg)
![Vue 3 Composition API Introduction [FULL TUTORIAL]](/img/1.gif)
I actually really like the update! It means you're just using vanilla javascript now and importing the api functions as you would any other library when just writing node. to be honest its kind of amazing to see a framework become less obtrusive as it matures.
Crisp and Clear, thank you :)
Awesome showcase!
at 23:50 could use return { ...useTodoApp() }
Or just return useTodoApp()
Excellent video! Would love another that touches on props, components, etc. with Vue 3 Composition API.
I am planning on building a real-world application soon as a tutorial. This will use all the current composition API’s capabilities. Will be good prep for when 3.0 releases.
Great video, very well explained 👌
Thank you man great explanation totally understood the concept of this composition API cheers 👍
Nice video man, really informative!
Good video, you're good at teaching - looking forward to more
karl charles Thanks Karl, I truly enjoy it too. Mid-November I’ll start uploading more frequently. Finishing off my degree now, so I don’t have too much time for RUclips.
@@KaizenCodes Well good luck with the degree. I'll turn notifications on for when you're back on RUclips
Good explanation thanks
awesome tutorial, a sneak peek about vuejs composition api
Nice work man!
RabbitWerks JavaScript thanks man. Appreciate it. Especially coming from you. 👍
@@KaizenCodes
Nice video...well explained, how does mapState, mapGetters etc fit into this new api
john m Hi, the Vuex library is still built on the options API, so currently there is no standard way to do this with composition. So whatever hack I come up with will probably be useless. We’ll have to wait for Vuex and Vue3. 👍
Hey there, thanks for the awesome video. I have a question why do you use Yarn over npm? Are there any benefits?
greetings from Johannesburg.
Solomon Tsaagane Hi Solomon. Hope you’re doing well and staying safe during this time in Jhb. I use Yarn because of it’s caching strategy and I’ve experienced less fails and faster speeds in general. But it’s not MUCH better and I do use NPM occasionally too.
Regards.
@@KaizenCodes thanks for sharing... I really appreciate it.
Awesome tutorial in just 23:16 minutes. Keep it up. Can you please show me how setup you VScode and the terminal
Short and to the point. Great videos so far! Any chance you could do a video dealing with Nuxt, nuxt/auth, nuxt/axios, and protected endpoints (passing a JWT in an axios request)? I'm hacking together an application and it works but I don't completely understand it. Cheers!
Great video. But what's the difference between this and Vuex? Can you explain? Thanks
Hi! At the moment it may seem similar because we’re importing the composition API into our app like we do Vuex (as if it is a plugin), but the API will soon be built into the core.
The two are fundamentally different in that Vuex is a state management plugin. You could think of it as pure data that Vue can look at and update it’s own properties based on changes in the store.
This API is more central to Vue’s MVVM design pattern. It hooks directly into the View Model. For example - if we add an @click to do some sort of method:
We have to dispatch an action from Vue to Vuex to let it know we want to call that method.
But with the composition API we can call that method directly on the view model. And that method can directly access data properties on the model, which directly triggers the view to update.
The Vuex store doesn’t access our component’s data, we have to explicitly set a computed or data property that links to Vuex state.
So basically Vuex is an external plugin to manage application-wide state as a 3rd party. Where the composition API IS the application model and interacts directly with the presentation layer.
I hope that makes sense. Very good question!
@@KaizenCodes thanks for the explanation!
The Vue composition api looks good and does look a lot better than the old one. But you could just use Vue.extend to share logic what was the problem with that way. In react you make custom hooks and react hooks to share logic. But I’m Vue we are now going to do the same thing but with Vue hooks and regular functions. By the way do you have a good understanding of Vue router I have not found any good cases for the router.beforeEach() method.
VideoVibes Hello! I understand what you mean. Extend still has the problem of grouping code by options instead of logical concerns though.
The beforeEach method is something I’ve used in authentication - to add route guards. So I would do something like check if the route is in the list of protected routes and if there is a user in the store; then continue if there is, otherwise redirect to /login. But that’s all I’ve used it for.
The way I've utilized router.beforeEach is checking to make sure a user is valid and logged in before serving the route.
Usually with jwt
Thank's a lot !!!
What theme are you using in vs code?
Cobalt2 by Wes Bos
excellent
Thank you
Thanks.
I don't see how this is useful :( You _claim_ that the composition API it is more readable... but well, that doesn't do it for me. How about explaining why?
You produced several errors in the video - which proves to me that this the new syntax is confusing. That is a pretty high price.. for what benefits? Having stuff somewhere outside in a function or in another file doesn't really make the code automatically better :/
dasten123 Hey. Sorry you feel that way. Luckily it’s not a necessity for everyone to like it or use it. It clicked for me because I remember working on a team where we had a horrible few thousand lines of code in a component. And the jumping up and down from methods to computed to data etc. Was a killer to refactor and understand. Maybe a big component will be a better example, but like I said. It’s not a necessity that you think it’s better or not. So just use the way you enjoy :)
@@KaizenCodes So... would you _only_ use this to refactor/prevent those giant components and for re-usable stuff? Or would you do it for small components like your example as well?
Because that is my problem.. People explain it with examples that make the code MUCH harder to understand and everyone is like "ahh, yeah, that makes sense!" And I just don't understand it... it's so frustrating
dasten123 I think it depends really. But I would wait for 3.0 to release first and see what happens - if I happen to work on a production app with/without it. I think if an app/site has no complex logic at all, in any component or view, I’d stick to the options API. But that’s very unlikely in the real-world.
If at least one or two components/views have multiple methods and properties - I’d just use the composition API all-round to keep it consistent. Depends on if I’m working in a team too and what their requirements are.
You are asking good questions and there is no need to get frustrated - because nobody reasons the same about stuff. It’s like many programming tutorials and guides that have the simple todo app or something like that, it’s not a fair representation of real large apps, but it’s really inefficient to try and explain fundamental concepts in huge videos with many different complexities.
Anyway, key point is that I never try to think someone else is wrong, because I am not able to reason like them. (Unless of course something is obviously wrong and everyone agrees). So you may be right, could be that it’s not going to make things better - but from my experience and the time I’ve spent with teams I can reflect on some definite projects that this would have been super helpful in test suites, code reviews and just consistency in general 👍
I have looked into the composition api a bit more and I now like it!
The thing that threw me off was that I loved Vue so much for it's simplicity and readability. And when I saw the new api, I thought this was over.
Now, I stay by the opinion that the composition-api _is_ confusing, but I realized that some of my larger components I have written with the options-api are confusing and unreadable as well.
I guess the love for Vue made me blind :/ I hope to be more open-minded in the future.
It reminds me of AngularJs totally awful and messy
Sergio Peña ok
Thank you