Please Like, Share, Subscribe & Comment - it all helps me create more content for you! 👉 My Courses: dannys.link/courses 👉 Download Fudget: www.fudget.com 👉 My VSCode Setup: dannys.link/vscodesetup 👉 DONT CLICK THIS: dannys.link/dontclick
@@jaymartinez311 right now I'm focused on creating my app Fudget 2 which is a huge project. However, I have toyed with the idea of doing a Vue 3 & Composition API course in the future. We'll see...
@@MakeAppswithDanny It would be great. This was the first time i have seen in a video that you used the composition api in a store outside the component and then injected it with a store instance. I know you did not like having to create a const store everywhere but coming from ios(me) that’s just a single source of truth and i would prefer to that vs a global store.
That's funny. I have just completed replacing my vuex store with the composition api yesterday. All my actions and mutations are now simple accessor functions. And today this video! Great Danny, as always!
@@MakeAppswithDanny Good idea. My code looks pretty similar to the code in the video in some parts. However, I exported the methods with the spread operator, so I don't have to write "methods." in front of the function name. I also put all the two-way data binding stuff (Vue models) in a separate file called useAccessors. Accessors combine my previous actions and mutations. I first started with inject and provide, but got away from it because I don't want to inject the whole store every time I just need a simple getter in a component. An alternative would be to have different stores. I'm creating my new project using the Quasar framework with the Composition API and pointless Typescript.... ;-) Typescript definitely helps me avoid typos that I would never have made. But writing Typescript has an interesting effect: the development speed slows down. Sometimes that's good. You really have to rethink your code when you're trying to get rid of those crappy type error messages... ;-) But the Quasar framework is really fun. I've also got my eye on Quasar 2 at the moment. So I expect to have to fix some parts of my code after it comes out. PS: Currently the @vue/composition-api plugin creates some errors in Quasar with provide/inject and also with reactive state in a Typescript file. But after some fiddling around I finally got it to work.
@@MakeAppswithDanny Good question... As an alternative to provide/inject you could create one of the new Vue 3 globalProperties and put the store there: v3.vuejs.org/guide/migration/global-api.html#vue-prototype-replaced-by-config-globalproperties I'm not sure if that would be a good idea. I don't believe in that old "global is evil" mantra, but I would just create a global store and then import only what is needed in the respective component. But for a simple store the global approach should work.
I see this fit for smaller projects and single developers as a lightweight alternative to Vuex. For a team and larger projects the normalized and documented API of Vuex ensures the consistency of store implementations.
Very refreshing to see a professional video, clear descriptions without extra narration or off topic comments - thank you for taking the time to share your knowledge!
Excellent crash course Danny; 1) I really prefer the composition API as it feels more natural in my head. Vuex feels more convoluted. 2) I bet, in a large app, the Composition API style will have a better reactivity performance than Vuex which requires a lot more Vue framework codes to execute. 3) The Composition API getter and Setter looks very similar to .Net property setter and getter. Danny, I like to make a video suggestion. Can you give us a video that basically provides steps what changes we need to make to our project to convert V2 app to V3 app with Composition API?
Hey thanks for this simple overview of Vue 3's composition API. There's a huge lack of good videos on architecting an app with it. Here's my feedback and suggestion for another video. I'm unclear why we'd use getters, or any of the VueX methods, with it. I think this confusion is about the broader confusion in the front-end world of finite state machines versus reactive streaming formalisms. Since you explain things very well with not too-simple example projects, I thought I'd share my wishlist of topics to cover in a video that explains how to architect an app with the composition API, that of course you're free to not follow up on. So: in contrast to VueX's finite state machine formalism, the Vue 3's observable reactive object is based on a streaming events formalism, that manages a stream of events through a job scheduler, which organizes time-stamped events into a queue of immediate or deferred events. Simulation modeling makes this formalism clear, and RXjs sort of makes this clear. It seems that much of the current thinking on Vue' 3's composition API's reactive observable object hasn't gone all the way into an event, or time-based, reactive streaming formalism. Most are still thinking about the reactive observable object as a finite state machine, which is more tedious to architect. Maybe a middle-ground approach for now is something like what the Aurelia.js front-end framework does with their Events Aggregator that's imported to components if they are sharing a value.
Great video. So glad I found this channel. Coming from a React & React Hooks background, the Composition API feels easier to understand though the "mutations/getters/setters" terminologies might need some getting used to. I might get into a bit of Vuex as well once I grasp the basics. Thanks again.
The last con you mentioned is actually a pro, imho. The global state, like vuex, very quickly becomes a god object we really would like to avoid. So, explicit importing is good for treeshaking and for readability, because everything is explicit.
Great video brother. New to Vue3, and I am just learning Composition API, it gave some great insights and tips on certain practices. Thank you for that! :)
Thanks for the lecture was explanatory; you broke down the concept of Composition API bravo!! You highlight the pros and cons in which kind of project would you use Composition Api or Option API? Thanks
Thanks Michele! To be honest I'm using Composition API exclusively now. I'll explain why on video 7 of my Real World Quasar App series, in a few weeks time: th-cam.com/video/OluD-GW8cRM/w-d-xo.html
I find this to be a more intuitive approach to application state management, certainly more flexible too. I liked how you outlined the pros and cons of this technique. P.S. Love your Remember-To-Subscribe animation. Very catchy :-)
Yes you can use async code in Actions (but not in mutations). This is the main reason I prefer Pinia over Vuex. In Pinia there are no mutations, only Actions. And in these you can have async code AND manipulate the state. Check out my Pinia tutorial: th-cam.com/video/JGC7aAC-3y8/w-d-xo.html
Great video. Seems like it make more sense if your getters were computed() so that they'll be reactive and only recompute when their dependencies change. It'll also mean you don't need parenthesis in the template. Right now, having the function call in the template means they'll recompute whenever the template updates.
Ian, I replaced all my Getters in Fudget 2 with Computed properties and it works great. It's important to note that when doing this we need to make our getters object reactive, like so: import { reactive, computed } from 'vue' const state = reactive({ entries: [ ... ] }) const getters = reactive({ entriesSorted: computed(() => { return state.entries.sort((a, b) => parseFloat(a.order) - parseFloat(b.order)) }), }) export default { state, getters } Like you say, we can then use the getter in a template without parentheses like so: If we want a getter that accepts parameters, for example a getter that gets a folder name based on a folder id: {{ store.budgets.getters.folderName(folderId) }} Then we need to set that up in the store like this: const getters = reactive({ folderName: computed(() => { return folderId => { let folderItem = state.budgets['folder-default'].filter(item => { return item.id === folderId })[0] return folderItem.name } }) }) Thanks for the tip, Ian!
@@MakeAppswithDanny awesome, glad it helped! It seems like there might be enough here for a potential follow up video on computeds. I definitely wouldn't say no to that.
Hi Danny! I enjoy very much your videos. I have learned with them a lot. I have a question about Quasar and Pinia. Can Pinia be used in Quasar instead of Vuex? I have googled but I have not found anything in concrete, I found in StackOverflow that it can be done by uninstalling Vuex and installing PInia. Have you tried to use Pinia with Quasar? Waiting for your comments. Best Regards, JB
Thanks Juan. I don't see any reason why it shouldn't work. I'm planning on switching my Quasar 2 (Vue 3) app Fudget over to Pinia soon. You can probably install it using a boot file (though I've not tried it yet). This might help: mokkapps.de/blog/building-a-vue-3-desktop-app-with-pinia-electron-and-quasar/#add-pinia-as-vue-store-library
Awesome content as usual 😉. I think the best practice of using composition api as state management by creating global composable function like useState, useCounter .. etc..then resuing those functions in any component
@@MakeAppswithDanny yes. I used setup function passing props as reactive states. And with the use of provide/inject api , I can pass the data in any component deeply. It's so powerful. It's much easier pattern than vuex for me.
Vuex 5 looks like the best option. After working on a Vue app for a year, being able to debug in Vue tools what was going on with the state was a must have. On the other hand, there was a very long list of mutations that needed to be created...
I usually implenent a helper function that allows for a simple automatic mutations generation based on the state object so my mutations usually looks like this: export const mutations = { ...generateMutations(state), // Some more complex mutations goes here } generateMutations looks like this: export function generateMutations(state, freeze = false) { const mutations = {} Object.keys(state()).forEach(prop => { mutations['set' + prop.charAt(0).toUpperCase() + prop.substr(1)] = (state, payload) => { state[prop] = freeze && typeof payload === 'object' ? Object.freeze(payload) : payload } }) return mutations }
It would be really interesting to see a deep breakdown of how composables should be created, for example, I figured out that if you want to keep part of reactive reference in memory you can create it outside of the exported composable function, that way you can simulate something similar to Vuex store module. What I'm getting at looks like this: const num1 = ref(0) // This will NOT be garbage collected once related component is destroyed export default () => { const num2 = ref(0) // This will be garbage collected once related component is destroyed ..... return { num1, num2 } } but I'm not sure how "clean" it is from a memory usage perspective. I also have doubts regarding the pattern to begin with since it looks unclear to what stays in memory. Vuex on that matter was much more clear, but I see a tendency in the community to move away from it
Do you think we still need XState ? I think we can do more with this way. More flexible and clean code, isn't it? I think Con 2 and 3 is not a big isse, only Con 1 debug may be a real issue.
Yes I'm creating Fudget 2 using Quasar at the moment & documenting it in a series that will start in a couple of weeks: "Creating a Real World Quasar App"
Hello Danny, Greetings from Kigali 🇷🇼, I was following your example i want to use a simple store to handle prices that barely change or mutate. My, QN is if i inject the store in a views file will the components being served from the view have access to store or do i inject the store in each component. Thank you
You might be able to avoid injecting it into every component by using provide (on a higher level component) which would make it available to all child components too 👍
This is a freaking awesome tutorial, definitely go with composition-api vuex way, I use vite to build app and I have hard time integrating vuex into it. With this tutorial I can achieve this taks now. Thank you Danny for this amazing tutorial !!!
Thanks Stephen. One thing to keep in mind, is that Vuex 5 is apparently going to get rid of mutations, so that you just have actions which can mutate the state (and be async). However, I'm not sure when this will be out.
@@MakeAppswithDanny that would be even better, so vue team try to work vuex redux way, it is good to not have mutations because it is a redundant and repetitive function !!!
Hey. Wonderful video! One question. How can I get IntelliSense working with the injected store? For some unknown reason the IntelliSense suggestions are not poping up. (I get the suggestions normally if I import the store instead of injecting it.)
The main problem of composition-api as I see right now is a very big potential for a "memory leak architecture". From the enterprise level project I am working on I saw a tendency among a lot of developers to put all logic inside composables and make all data available globally to the app, without a proper thought on how that data is cleared when navigating between routes. This creates huge issues with clearing the state and since we still don't have proper tools (similar to Vuex) for debugging those composables - it's very hard to tell what data is currently stored in memory. Another issue is a very big fragmentation on entities. On one hand developers try to make composables as small as possible to make for a flexible composition, but on the other hand it means that we no longer can easily tell about how those entities relates to each other. Overall I can say that architecting apps based on composition-api is very challenging and I still haven't found a good official reference and recommendations on best practices of architecting a good composable.
Is it really necessary to provide/inject here? I think we can just import the state object exported from store/index.js and use directly within the component (similar to using a composable, but no real need to wrap it in a function since we don't want a scoped state)
I would still use vuex because of all the cons you mentioned. I don't mind excessive actions and mutations in my codebase because It makes me looks smart and boosts my ego
This seems to be better for when your application state doesn't contain critical data (where easily knowing what component triggered a mutation incorrectly would be beneficial to debugging). Since the composable store itself is part of the setup() function export (at least in this demo), the current data contained within should be visible as part of a component's data members in Vue DevTools as you modify it in real time, and thus this approach is fine for simply seeing how the data in the store changes. Relying on this to debug becomes exponentially less effective the more components utilize a single composable store throughout the app, as the origin of the change becomes harder to track. So I guess this is all to say that this seems best for when time traversal isn't needed or the data contained in the store itself isn't complex (and thus the ways to modify it/places it could change are hopefully minimal)
I actually just did this a week ago, vue3 with vuex + typescript was getting unmanageable so I decided to scrap it and just write state wrapped by reactive(). Then all the properties that can be derived from that state are computed properties returned by little functions used across the site
@@MakeAppswithDanny For typescript I think import/export preserve types, so it's safer. But maybe it's possible to preserve types for inject/provide too. I have no idea to be honest :)
I haven't tried it but this might do the job: github.com/robinrodricks/vue3-touch-events Or there might be a composable in VueUse that will do the job: vueuse.org/
@@ugurtigu He is calling a method in the computed property, that passes the new value to, to change the value from within the store. He is not accessing the store state directly like: store.state.counter, but rather store.methods.changeCode, which when called with the given payload, it replaces the store value with the payload provided. The method that is called, is not in the component, but in the store. It's similar to mutations in Vuex.
Quasar now supports VueJS 3. Vuetify isn't there yet but VueJS 3 support is pencilled in for Q3 2021. So this alone doesn't quite feel like a reason to pick Quasar. So how to choose between Vuetify and Quasar for a web app? Any advice? If anyone should know the answer to this question you should!
For a straightforward web app, you are mainly concerned about the Component Library. And both Frameworks have more or less identical Component Libraries, but Quasar has some extra bells and whistles which make things easier - for example the notification, loading & dialog plugins which make it really easy to display notifications, loading screens and dialogs with a couple of lines of code. These plugins are not included with Vuetify, so you need to put quite a bit more work into your own solutions. But it also depends on your broader goals. If you are just creating an app for yourself, I would say Quasar is the best option. If you're trying to get a job, then Vuetify might be better as it's more broadly used by companies.
@@MakeAppswithDanny Thanks Danny, great answer! I can see how Quasar has the edge on Vuetify and find myself wondering why Vuetify is so much more popular when it seems like Quasar has more momentum. Mind you I feel the same about React and VueJS. Why everyone is drinking the XML in JS kool-aid is beyond me 🙄 ps Enjoyed your udemy courses, keep em coming. Poo bananas 💩🍌😂
Hi Dany, Thank you very much for this wonderful work, I converted my state management based on vuex to composition Api, until then everything was fine, but when I started adding to LocalBase I got this error message "localbase Could not add Document to todoList collection", do you think the problem is with proxy object? if so can we change proxy object to normal object?
Are you trying to store the whole of your state in Localbase? If so, yeah it could be because it's a reactive object. Perhaps you could just store a particular property from the state in Locabase instead? Or try one of these suggestions: stackoverflow.com/questions/53102700/how-do-i-turn-an-es6-proxy-back-into-a-plain-object-pojo
There are simpler ways to use and/or change reactive variables across application. No need to use 'inject' and 'provide'. Just import a file with stored reactive variables and use it in components where you need it. I think it's much more simple from the cognitive point of view, no need to think about additional setups in order to make it work.
hi Danny and thanks for this wonderful tutorial, I have a question about the benefits of using set and get method compare using normal only two ways of data binding data, beside of the readonly state props. thankyou and god bless you!
Thanks! The benefit of using the readonly method is that you can protect your state from outside mutations - I.E outside of the store file (to make sure all code that manipulates the state is in one place). This is a personal preference though. In my app Fudget 2, I'm manipulating the state from outside of the store.
Not currently. You can grab the code for some of the videos on my website, www.dconnell.co.uk However I'll be putting more stuff on GitHub from now on, starting with the code for my forthcoming course, Vue 3: Composition API (with Pinia & Vite). 👍
I'm kinda curious if we HAVE to use inject method in order to let all the components see the store, why don't we just import it to any component without injecting?
For some reason my vue says 'An error occurred in hook walkComponentTree' any ideas? Thanks. It happens only when I reference store.state.counter in the template..
I see the similarity to React store (Redux and Context API). React Context API can force not only used components but also other unused components to rerender. It translates into worse performance. Can Composition API store have worse performance than Vuex?
Good question. I'm not sure, but I don't see why it would, since Vue 3 is based on Composition API. So using it in a separate file shouldn't be any different. But again, I don't know for sure.
@@MakeAppswithDanny provide/inject is just a construct for passing reactive value down to deely nested child components from parent, it's a Vue 2 workaround when you can't use Vuex or eventBus. Since vue-composition API was developed specifically to address such issues - there is no longer a need to use provide/inject since now you can move all the reactive behavior into composable and import it wherever you like. Try to replace provide/inject with just imports and I think everything will still be working as it was. I think the only case when you still want to use provide/inject is when you don't use composables, for example in case of atomic component design, where you want your organism component to have fully encapsulated state that has 0 business logic and fully belongs to this one specific component internal structure
If you mean with Vue devtools - I don't think Vue devtools works once the app is built for production - I might be wrong though. If it does still work, I guess there's not much you can do, besides setting up your app so that the user messing with the state can't cause any damage.
@@MakeAppswithDanny I noticed a while ago that when I start the server on localhost by typing npm run serve in visual studio and go to my site via the chrome browser and press F12 I can access the Vue tab - developer tools. I can change various state values there, for example once I changed the isLoggedIn state to true and I could send a message to a chat without being authorized in google.... I hacked my own app :< Because the isLoggedIn value was driving almost all the app logic. So I moved all such important values like isLoggedIn etc to store.js. When you replied me on YT something flashed in my empty head. I went into my app which is hosted on netlify and noticed that it was impossible to enable those Vue Tools. So it comes out that after uploading my site to netlify the project is not in development build mode.... That's good, which means I don't have to keep all the data in the store. Because of such a small thing almost all Vue learning came to a standstill....
Composition API pros definetly exceed the cons. Not to mention the performance... I guess the composition API should outperform vuex or any other vue2 technique according to the announcements made by Evan You when launching Ccomposition API. Maybe the debugger might be a prb but still....
@@MakeAppswithDanny You are the boss here ;-). It would be great if we just could have a Chrome extension as an alternative for debugging. If built with quasar or not, it doesn't really matter.
Hi Danny, sorry to pickup on this old video. I have a problem. In my case, when i enter the color code "red", the computer setter function only store one character and when i enter the next character it only register the second input and loses the first one. This happens only when i have tthe code "store.methods.setColorCode(val)" in the setter. If i remove this code and use the console.log to dump the "val" its appears to be ok. Please help.
@@SAIEN333 because click handlers in Vue (e.g. Click me ) always assume the name of a method is being passed in (unless you fire some specific code such as @click="counter++". So Vue basically figures this out for you. If you were to call a method within double curly braces {{ }} or within your setup code, you would need to provide the parentheses at the end of the method name 👍
JUST SUBSCRIBED! Thanks for this amazing tutorial But for some reason the Watch method does notdetect any changes Example: Component 1 Injects store and changes it, this component has a "watch(store.state, () => {...} )" inside the setup function to see what changed. Component 1 calls Component 2 using Vue Router **Note that component 2 is not a component 1 child, it is a component in a different route"* Component 2 Also injects the store and also changes it , the watch on the component 1 doesnt fire Can someone help me... please?
Do you have at least part of that code you are trying to debug somewhere online? I understand what you are trying to achieve, but the same thing you said can be implemented in hundred ways. :)
it's true the composition api is smaller and comfortable, but how about multi `store/` then what ? for example we have vuex for USERS and we have a other vuex for ORDER, in vuex we create two file for each one , but in this way (composition api) is more difficult and I can't understand it . can u (@MakeAppswithDanny) or someone explain it for me ?
You basically just create a separate composable for each store, e.g. create useStoreUsers.js (and add all your user data & methods) then create a useStoreOrders.js composable (and add your order data & methods).
![[ВАЖНО - Читай описание] Почему вы просто обязаны использовать VUEX в своем приложении!](/img/n.gif)
Please Like, Share, Subscribe & Comment - it all helps me create more content for you!
👉 My Courses: dannys.link/courses
👉 Download Fudget: www.fudget.com
👉 My VSCode Setup: dannys.link/vscodesetup
👉 DONT CLICK THIS: dannys.link/dontclick
Can I use Composition API for state management with Typescript, please reply Mr.Danny Connell
Are you going to release a course using the composition api? 🤔
@@jaymartinez311 right now I'm focused on creating my app Fudget 2 which is a huge project. However, I have toyed with the idea of doing a Vue 3 & Composition API course in the future. We'll see...
@@MakeAppswithDanny It would be great. This was the first time i have seen in a video that you used the composition api in a store outside the component and then injected it with a store instance. I know you did not like having to create a const store everywhere but coming from ios(me) that’s just a single source of truth and i would prefer to that vs a global store.
That's funny. I have just completed replacing my vuex store with the composition api yesterday. All my actions and mutations are now simple accessor functions. And today this video! Great Danny, as always!
Thanks Jens! Yeah I'm considering using this State Management for the app I'm working on!
@@MakeAppswithDanny Good idea. My code looks pretty similar to the code in the video in some parts. However, I exported the methods with the spread operator, so I don't have to write "methods." in front of the function name. I also put all the two-way data binding stuff (Vue models) in a separate file called useAccessors. Accessors combine my previous actions and mutations. I first started with inject and provide, but got away from it because I don't want to inject the whole store every time I just need a simple getter in a component. An alternative would be to have different stores. I'm creating my new project using the Quasar framework with the Composition API and pointless Typescript.... ;-) Typescript definitely helps me avoid typos that I would never have made. But writing Typescript has an interesting effect: the development speed slows down. Sometimes that's good. You really have to rethink your code when you're trying to get rid of those crappy type error messages... ;-) But the Quasar framework is really fun. I've also got my eye on Quasar 2 at the moment. So I expect to have to fix some parts of my code after it comes out. PS: Currently the @vue/composition-api plugin creates some errors in Quasar with provide/inject and also with reactive state in a Typescript file. But after some fiddling around I finally got it to work.
@@jensluck370 thanks Jens. Would it be possible to add the store to the main Vue instance so we don’t need to keep injecting it?
@@MakeAppswithDanny Good question... As an alternative to provide/inject you could create one of the new Vue 3 globalProperties and put the store there: v3.vuejs.org/guide/migration/global-api.html#vue-prototype-replaced-by-config-globalproperties
I'm not sure if that would be a good idea. I don't believe in that old "global is evil" mantra, but I would just create a global store and then import only what is needed in the respective component. But for a simple store the global approach should work.
I see this fit for smaller projects and single developers as a lightweight alternative to Vuex. For a team and larger projects the normalized and documented API of Vuex ensures the consistency of store implementations.
Yeah good points Alexander 👍
I hold a similar view
🍍
Omg, so good! Finally the composition API is no mystery anymore! Thanks a lot!
Thanks Lukas! Glad it was helpful!
Very refreshing to see a professional video, clear descriptions without extra narration or off topic comments - thank you for taking the time to share your knowledge!
Glad it was helpful!
Excellent crash course Danny;
1) I really prefer the composition API as it feels more natural in my head. Vuex feels more convoluted.
2) I bet, in a large app, the Composition API style will have a better reactivity performance than Vuex which requires a lot more Vue framework codes to execute.
3) The Composition API getter and Setter looks very similar to .Net property setter and getter.
Danny, I like to make a video suggestion. Can you give us a video that basically provides steps what changes we need to make to our project to convert V2 app to V3 app with Composition API?
Nice and clear explanation, thanks Danny
You're welcome, thanks Hasan!
Hey thanks for this simple overview of Vue 3's composition API. There's a huge lack of good videos on architecting an app with it. Here's my feedback and suggestion for another video. I'm unclear why we'd use getters, or any of the VueX methods, with it. I think this confusion is about the broader confusion in the front-end world of finite state machines versus reactive streaming formalisms. Since you explain things very well with not too-simple example projects, I thought I'd share my wishlist of topics to cover in a video that explains how to architect an app with the composition API, that of course you're free to not follow up on. So: in contrast to VueX's finite state machine formalism, the Vue 3's observable reactive object is based on a streaming events formalism, that manages a stream of events through a job scheduler, which organizes time-stamped events into a queue of immediate or deferred events. Simulation modeling makes this formalism clear, and RXjs sort of makes this clear. It seems that much of the current thinking on Vue' 3's composition API's reactive observable object hasn't gone all the way into an event, or time-based, reactive streaming formalism. Most are still thinking about the reactive observable object as a finite state machine, which is more tedious to architect. Maybe a middle-ground approach for now is something like what the Aurelia.js front-end framework does with their Events Aggregator that's imported to components if they are sharing a value.
It becomes much easier to understand composition api by watching your video.
Thanks. Glad it was helpful!
Wonderful. ❤️❤️❤️ Am gonna stick with VueX. But this techniques provides more insight to the vue3 flexibility 👍👍👍
...
Quality video 🏆🏆🏆
Thanks Susanth!
Great video. So glad I found this channel. Coming from a React & React Hooks background, the Composition API feels easier to understand though the "mutations/getters/setters" terminologies might need some getting used to. I might get into a bit of Vuex as well once I grasp the basics. Thanks again.
Awesome, thank you!
The last con you mentioned is actually a pro, imho. The global state, like vuex, very quickly becomes a god object we really would like to avoid. So, explicit importing is good for treeshaking and for readability, because everything is explicit.
Good point, Peter 👍
Dude your the best at teaching vue here on youtube!! thank you so much bro
Thanks Alex, much appreciated!
2 questions and you solved it in 2 videos, You got a new subscriber now :) very clear and straight farword, thanks
Thanks Muhammad!
Great video brother. New to Vue3, and I am just learning Composition API, it gave some great insights and tips on certain practices.
Thank you for that! :)
Glad it was helpful!
I like this composition api style instead using vuex. We can purely design the store in simple OOP way. Thanks for sharing
Yeah I prefer it too Mirza 👍
Thanks for me was more easy use in this way instead vuex. Excelent tutorial as usual
Thanks Werner. Glad it helped! 👍
Excellent tutorial! Thank you so much for making it. It was super insightful.
Great to hear, thanks Marcos!
AWESOME VIDEO!!!! Thanks! your videos are great!
Thank you bithigh!
Perfect learning material. Thanks and subscribed!
Thanks and welcome! 👍
Thanks for making this tutorial 🙏. This video helped me understand that term
Glad it was helpful!
Thank you for this video, I implemented this solution for a brand new project and it rocks !!! ;)
Great! Yeah I'm loving this approach too in Fudget 2. I'm actually not missing the devtool capabilities of Vuex that much 👍
Thanks for the lecture was explanatory; you broke down the concept of Composition API bravo!!
You highlight the pros and cons in which kind of project would you use Composition Api or Option API?
Thanks
Thanks Michele! To be honest I'm using Composition API exclusively now. I'll explain why on video 7 of my Real World Quasar App series, in a few weeks time: th-cam.com/video/OluD-GW8cRM/w-d-xo.html
Hej Danny, would be amazing if you could provide something with composition API and typescript, thanks again !!
I find this to be a more intuitive approach to application state management, certainly more flexible too. I liked how you outlined the pros and cons of this technique. P.S. Love your Remember-To-Subscribe animation. Very catchy :-)
Thanks Les 👍
Thanks bro. Your videos are very usefull for me
Thanks Shaxzod! 👍
Amazing video!
Thank you Danny!
Thanks Mike, glad it was helpful!
The Composition API is tops!
I know I was apprehensive at first, but really like it now.
Great video, but I'm wondering if it is possible to adopt things like mutation and actions (vuex) to deal with API data from Axios
Yes you can use async code in Actions (but not in mutations). This is the main reason I prefer Pinia over Vuex. In Pinia there are no mutations, only Actions. And in these you can have async code AND manipulate the state. Check out my Pinia tutorial: th-cam.com/video/JGC7aAC-3y8/w-d-xo.html
Great video. Seems like it make more sense if your getters were computed() so that they'll be reactive and only recompute when their dependencies change. It'll also mean you don't need parenthesis in the template. Right now, having the function call in the template means they'll recompute whenever the template updates.
Yes Ian that's a good idea, I will give that a try 👍
Ian, I replaced all my Getters in Fudget 2 with Computed properties and it works great. It's important to note that when doing this we need to make our getters object reactive, like so:
import { reactive, computed } from 'vue'
const state = reactive({
entries: [
...
]
})
const getters = reactive({
entriesSorted: computed(() => {
return state.entries.sort((a, b) => parseFloat(a.order) - parseFloat(b.order))
}),
})
export default {
state,
getters
}
Like you say, we can then use the getter in a template without parentheses like so:
If we want a getter that accepts parameters, for example a getter that gets a folder name based on a folder id:
{{ store.budgets.getters.folderName(folderId) }}
Then we need to set that up in the store like this:
const getters = reactive({
folderName: computed(() => {
return folderId => {
let folderItem = state.budgets['folder-default'].filter(item => { return item.id === folderId })[0]
return folderItem.name
}
})
})
Thanks for the tip, Ian!
@@MakeAppswithDanny awesome, glad it helped! It seems like there might be enough here for a potential follow up video on computeds. I definitely wouldn't say no to that.
@@soviut303 I agree, give me more.... ;)
Hi Danny!
I enjoy very much your videos. I have learned with them a lot.
I have a question about Quasar and Pinia. Can Pinia be used in Quasar instead of Vuex?
I have googled but I have not found anything in concrete, I found in StackOverflow that it can be done by uninstalling Vuex and installing PInia.
Have you tried to use Pinia with Quasar?
Waiting for your comments.
Best Regards,
JB
Thanks Juan. I don't see any reason why it shouldn't work. I'm planning on switching my Quasar 2 (Vue 3) app Fudget over to Pinia soon. You can probably install it using a boot file (though I've not tried it yet). This might help: mokkapps.de/blog/building-a-vue-3-desktop-app-with-pinia-electron-and-quasar/#add-pinia-as-vue-store-library
Awesome content as usual 😉. I think the best practice of using composition api as state management by creating global composable function like useState, useCounter .. etc..then resuing those functions in any component
Thanks Amer. Yes, that could work. Have you tried it?
@@MakeAppswithDanny yes. I used setup function passing props as reactive states. And with the use of provide/inject api , I can pass the data in any component deeply. It's so powerful. It's much easier pattern than vuex for me.
Vuex 5 looks like the best option. After working on a Vue app for a year, being able to debug in Vue tools what was going on with the state was a must have. On the other hand, there was a very long list of mutations that needed to be created...
Yeah I wish Vuex 5 was out now!
I usually implenent a helper function that allows for a simple automatic mutations generation based on the state object so my mutations usually looks like this:
export const mutations = {
...generateMutations(state),
// Some more complex mutations goes here
}
generateMutations looks like this:
export function generateMutations(state, freeze = false) {
const mutations = {}
Object.keys(state()).forEach(prop => {
mutations['set' + prop.charAt(0).toUpperCase() + prop.substr(1)] = (state, payload) => {
state[prop] = freeze && typeof payload === 'object' ? Object.freeze(payload) : payload
}
})
return mutations
}
composition api of course ' great talk thanks
Thanks Michael! 👍
This was brilliant. Thank you.
Thanks!
It would be really interesting to see a deep breakdown of how composables should be created, for example, I figured out that if you want to keep part of reactive reference in memory you can create it outside of the exported composable function, that way you can simulate something similar to Vuex store module. What I'm getting at looks like this:
const num1 = ref(0) // This will NOT be garbage collected once related component is destroyed
export default () => {
const num2 = ref(0) // This will be garbage collected once related component is destroyed
.....
return {
num1,
num2
}
}
but I'm not sure how "clean" it is from a memory usage perspective. I also have doubts regarding the pattern to begin with since it looks unclear to what stays in memory. Vuex on that matter was much more clear, but I see a tendency in the community to move away from it
Thanks ! So simple... Best tutorial ever !
Wow thanks effset!
awesome content thanks it's very helpful
Glad it was helpful Loïc!
Great video. Thank you.
Pleasure thanks WarRaupe!
Thanks from Brazil
Thanks Felipe. My pleasure from Manchester 👍
Thank you for this video. You've helped me unlock a lot of potential.
Glad to hear it!
Do you think we still need XState ? I think we can do more with this way. More flexible and clean code, isn't it? I think Con 2 and 3 is not a big isse, only Con 1 debug may be a real issue.
I'm not sure Can...
Really great example and use case.
Thanks! 😃
Thanks again, Danny, you are the best!
Thanks Page. So are you 👍
Long time follower, Danny. Do you have plans to make and release any quasar based commercial app like fudget?
Yes I'm creating Fudget 2 using Quasar at the moment & documenting it in a series that will start in a couple of weeks: "Creating a Real World Quasar App"
@@MakeAppswithDanny That's so awesome!
That is just i looking for, thanks
Great Qb!
Hello Danny, Greetings from Kigali 🇷🇼, I was following your example i want to use a simple store to handle prices that barely change or mutate. My, QN is if i inject the store in a views file will the components being served from the view have access to store or do i inject the store in each component. Thank you
You might be able to avoid injecting it into every component by using provide (on a higher level component) which would make it available to all child components too 👍
@@MakeAppswithDanny Thank you, let me try will be back if i get stuck or something else comes up.
For a beginner, you move a little fast but still very helpful
Thanks. I realised yesterday I'm talking a lot more slowly in my latest videos (I'm not sure why!), hopefully that helps 👍
Awesome! Thanks a lot for this! I like that approach much more than vuex!
Thanks Tomas, me too! 👍
This is a freaking awesome tutorial, definitely go with composition-api vuex way, I use vite to build app and I have hard time integrating vuex into it. With this tutorial I can achieve this taks now. Thank you Danny for this amazing tutorial !!!
Thanks Stephen. One thing to keep in mind, is that Vuex 5 is apparently going to get rid of mutations, so that you just have actions which can mutate the state (and be async). However, I'm not sure when this will be out.
@@MakeAppswithDanny that would be even better, so vue team try to work vuex redux way, it is good to not have mutations because it is a redundant and repetitive function !!!
@@maskman4821 Agreed 👍
Look this man is genius
Hey. Wonderful video! One question. How can I get IntelliSense working with the injected store? For some unknown reason the IntelliSense suggestions are not poping up. (I get the suggestions normally if I import the store instead of injecting it.)
Hmm that's a good question, I'm not sure unfortunately. I suppose there's no harm in importing it instead if you need the intellisense.
The main problem of composition-api as I see right now is a very big potential for a "memory leak architecture". From the enterprise level project I am working on I saw a tendency among a lot of developers to put all logic inside composables and make all data available globally to the app, without a proper thought on how that data is cleared when navigating between routes. This creates huge issues with clearing the state and since we still don't have proper tools (similar to Vuex) for debugging those composables - it's very hard to tell what data is currently stored in memory. Another issue is a very big fragmentation on entities. On one hand developers try to make composables as small as possible to make for a flexible composition, but on the other hand it means that we no longer can easily tell about how those entities relates to each other. Overall I can say that architecting apps based on composition-api is very challenging and I still haven't found a good official reference and recommendations on best practices of architecting a good composable.
Good points Andrey 👍
Is it really necessary to provide/inject here? I think we can just import the state object exported from store/index.js and use directly within the component (similar to using a composable, but no real need to wrap it in a function since we don't want a scoped state)
Yeah that's fine 👍
First of all, thank you for sharing with us your knowledge. Is this also possible using Typescript?
Yes I believe Vue 3 is pretty optimised for Typescript. I still haven't got around with playing with it yet though.
This is even better using typescript than vuex is honestly.
Can you create a video on Vuex and Vue3 using composition API. The structure of the project should be modular?
Thanks Atif I'll consider it 👍
@@MakeAppswithDanny Thanks Danny ❤️
I would still use vuex because of all the cons you mentioned. I don't mind excessive actions and mutations in my codebase because It makes me looks smart and boosts my ego
😂
This seems to be better for when your application state doesn't contain critical data (where easily knowing what component triggered a mutation incorrectly would be beneficial to debugging).
Since the composable store itself is part of the setup() function export (at least in this demo), the current data contained within should be visible as part of a component's data members in Vue DevTools as you modify it in real time, and thus this approach is fine for simply seeing how the data in the store changes. Relying on this to debug becomes exponentially less effective the more components utilize a single composable store throughout the app, as the origin of the change becomes harder to track.
So I guess this is all to say that this seems best for when time traversal isn't needed or the data contained in the store itself isn't complex (and thus the ways to modify it/places it could change are hopefully minimal)
I actually just did this a week ago, vue3 with vuex + typescript was getting unmanageable so I decided to scrap it and just write state wrapped by reactive(). Then all the properties that can be derived from that state are computed properties returned by little functions used across the site
Great to hear. Yeah I just replaced all of getters in Fudget with computed properties, which is working really well 👍
Good content, thx!
Thanks Sergey, glad it was helpful! 👍
great video!!!
Thanks Sorn 👍
Hi! Could you explain difference between provide method and just exporting data in module and importing everywhere where needed?
That's a good question. I'm not sure if there are any benefits of provide / inject over export / import. Please let us know here if you find out.
@@MakeAppswithDanny For typescript I think import/export preserve types, so it's safer. But maybe it's possible to preserve types for inject/provide too. I have no idea to be honest :)
How can i accomplish to continously count up as long as the "+" button is pressed? Any tips? Came across mouseup and mousedown events...
I haven't tried it but this might do the job: github.com/robinrodricks/vue3-touch-events
Or there might be a composable in VueUse that will do the job: vueuse.org/
Nice example... But didn't you change the state still at the end?
Thanks Ugur. I don't understand your question?
@@MakeAppswithDanny I mean you made it read-only but still mutating the state.
@@ugurtigu He is calling a method in the computed property, that passes the new value to, to change the value from within the store.
He is not accessing the store state directly like: store.state.counter, but rather store.methods.changeCode, which when called with the given payload, it replaces the store value with the payload provided. The method that is called, is not in the component, but in the store. It's similar to mutations in Vuex.
Quasar now supports VueJS 3. Vuetify isn't there yet but VueJS 3 support is pencilled in for Q3 2021.
So this alone doesn't quite feel like a reason to pick Quasar. So how to choose between Vuetify and Quasar for a web app? Any advice? If anyone should know the answer to this question you should!
For a straightforward web app, you are mainly concerned about the Component Library. And both Frameworks have more or less identical Component Libraries, but Quasar has some extra bells and whistles which make things easier - for example the notification, loading & dialog plugins which make it really easy to display notifications, loading screens and dialogs with a couple of lines of code. These plugins are not included with Vuetify, so you need to put quite a bit more work into your own solutions. But it also depends on your broader goals. If you are just creating an app for yourself, I would say Quasar is the best option. If you're trying to get a job, then Vuetify might be better as it's more broadly used by companies.
@@MakeAppswithDanny Thanks Danny, great answer! I can see how Quasar has the edge on Vuetify and find myself wondering why Vuetify is so much more popular when it seems like Quasar has more momentum. Mind you I feel the same about React and VueJS. Why everyone is drinking the XML in JS kool-aid is beyond me 🙄
ps Enjoyed your udemy courses, keep em coming. Poo bananas 💩🍌😂
Hi Dany,
Thank you very much for this wonderful work, I converted my state management based on vuex to composition Api, until then everything was fine, but when I started adding to LocalBase I got this error message "localbase Could not add Document to todoList collection",
do you think the problem is with proxy object? if so can we change proxy object to normal object?
Are you trying to store the whole of your state in Localbase? If so, yeah it could be because it's a reactive object. Perhaps you could just store a particular property from the state in Locabase instead? Or try one of these suggestions: stackoverflow.com/questions/53102700/how-do-i-turn-an-es6-proxy-back-into-a-plain-object-pojo
@@MakeAppswithDanny
Thank you very much Danny,
JSON.parse (JSON.stringify (proxyObj)) work for me
Cons 4, inject() can only be used inside setup() or functional components.
I have to build a small app and vuex seemed like a huge hassle. This is great!
Great! Good luck with your app! 👍
Good video. Test IONIC VUE please.
No plans at the moment, but I'll consider it.
There are simpler ways to use and/or change reactive variables across application. No need to use 'inject' and 'provide'. Just import a file with stored reactive variables and use it in components where you need it. I think it's much more simple from the cognitive point of view, no need to think about additional setups in order to make it work.
True 👍
hi Danny and thanks for this wonderful tutorial, I have a question about the benefits of using set and get method compare using normal only two ways of data binding data, beside of the readonly state props. thankyou and god bless you!
Thanks! The benefit of using the readonly method is that you can protect your state from outside mutations - I.E outside of the store file (to make sure all code that manipulates the state is in one place). This is a personal preference though. In my app Fudget 2, I'm manipulating the state from outside of the store.
Is there a way to download your samples on github?
Not currently. You can grab the code for some of the videos on my website, www.dconnell.co.uk However I'll be putting more stuff on GitHub from now on, starting with the code for my forthcoming course, Vue 3: Composition API (with Pinia & Vite). 👍
are you supposed to do anything differently in a Quasar app? And is it better to have a boot store file?
You can basically do it the same way. Though you might want a boot file to just provide/inject your store. I did this in Fudget 2.
I'm kinda curious if we HAVE to use inject method in order to let all the components see the store, why don't we just import it to any component without injecting?
Good question. I'm not sure but I imagine just importing it will have the same performance.
@@MakeAppswithDanny one of the benefits of importing is that Vetur is able to offer predictions and intellisense when accessing the store object
Hello! Can I use async function in state management file directly? Actually I want to fetch data from server and assign it to a variable inside state.
Sure. You could do it something like this:
const actions = {
myFunc: async () => {
await myResultHere
}
}
@@MakeAppswithDanny Thanks a lot, Danny.
Hey Danny, is it possible to use or incorporate Graphql with the composition api for state management? If yes, then how?
I've not used Graphql, but I don't see why not. You should be able to use any REST-type backend with Quasar.
For some reason my vue says 'An error occurred in hook walkComponentTree' any ideas? Thanks. It happens only when I reference store.state.counter in the template..
I've no idea Anupam. Best of luck! 👍
@@MakeAppswithDanny Thanks.. I solved it.. I don't remember how.. But it works!! And that was an awesome tutorial!
great content 👍
Thanks Ashish!
why not use computed properties for the getters?
yes you can do 👍
Perfect explanation ! +1 sub ))
Thanks and welcome!
if there more than one input, what would you do?
You could have multiple state properties, or put all of your form fields in an object with a property for each field.
I see the similarity to React store (Redux and Context API). React Context API can force not only used components but also other unused components to rerender. It translates into worse performance. Can Composition API store have worse performance than Vuex?
Good question. I'm not sure, but I don't see why it would, since Vue 3 is based on Composition API. So using it in a separate file shouldn't be any different. But again, I don't know for sure.
capo pela
Grazie Alfredo!
I don't understand the reason for provide/inject here. Why you don't just import those using import statement in the component you want to use it?
Good point, I'm not sure if there is any difference performance wise 👍
@@MakeAppswithDanny provide/inject is just a construct for passing reactive value down to deely nested child components from parent, it's a Vue 2 workaround when you can't use Vuex or eventBus. Since vue-composition API was developed specifically to address such issues - there is no longer a need to use provide/inject since now you can move all the reactive behavior into composable and import it wherever you like. Try to replace provide/inject with just imports and I think everything will still be working as it was. I think the only case when you still want to use provide/inject is when you don't use composables, for example in case of atomic component design, where you want your organism component to have fully encapsulated state that has 0 business logic and fully belongs to this one specific component internal structure
thanks thanks thanks
Welcome welcome welcome! 👍
How do I protect the state from being changed in the browser development tools?
If you mean with Vue devtools - I don't think Vue devtools works once the app is built for production - I might be wrong though. If it does still work, I guess there's not much you can do, besides setting up your app so that the user messing with the state can't cause any damage.
@@MakeAppswithDanny I noticed a while ago that when I start the server on localhost by typing npm run serve in visual studio and go to my site via the chrome browser and press F12 I can access the Vue tab - developer tools. I can change various state values there, for example once I changed the isLoggedIn state to true and I could send a message to a chat without being authorized in google.... I hacked my own app :< Because the isLoggedIn value was driving almost all the app logic. So I moved all such important values like isLoggedIn etc to store.js. When you replied me on YT something flashed in my empty head. I went into my app which is hosted on netlify and noticed that it was impossible to enable those Vue Tools. So it comes out that after uploading my site to netlify the project is not in development build mode.... That's good, which means I don't have to keep all the data in the store. Because of such a small thing almost all Vue learning came to a standstill....
Composition API pros definetly exceed the cons. Not to mention the performance... I guess the composition API should outperform vuex or any other vue2 technique according to the announcements made by Evan You when launching Ccomposition API. Maybe the debugger might be a prb but still....
Yeah I would assume the performance would be better. I wonder if we could create a Chrome extension with Quasar for debugging?
@@MakeAppswithDanny You are the boss here ;-). It would be great if we just could have a Chrome extension as an alternative for debugging. If built with quasar or not, it doesn't really matter.
Hi Danny, sorry to pickup on this old video. I have a problem. In my case, when i enter the color code "red", the computer setter function only store one character and when i enter the next character it only register the second input and loses the first one. This happens only when i have tthe code "store.methods.setColorCode(val)" in the setter. If i remove this code and use the console.log to dump the "val" its appears to be ok. Please help.
I'm not sure what's going on there, Murugappan...
@@MakeAppswithDanny Thank you danny. Where can i get your completed code for this vid? I could use it to test if it works with your code.
@@truthteachers I don't think it's available online
@@MakeAppswithDanny ok thank you.
Can I pass arguments to a function in a composition API store?
Sure you can Thomas 👍
Why do we need () for gatter functions and not for the method's functions?
I'm not sure what you mean. Could you explain more and provide a timestamp? Cheers 👍
@@MakeAppswithDanny at 18:50
where you added braces, but on other functions you just added function name without ()
@@SAIEN333 because click handlers in Vue (e.g. Click me ) always assume the name of a method is being passed in (unless you fire some specific code such as @click="counter++". So Vue basically figures this out for you. If you were to call a method within double curly braces {{ }} or within your setup code, you would need to provide the parentheses at the end of the method name 👍
@@MakeAppswithDanny wo this was new for me , and very important to know.
thank you, for the kind reply. love your content❤
@@SAIEN333 Thanks, no problem 👍
JUST SUBSCRIBED!
Thanks for this amazing tutorial
But for some reason the Watch method does notdetect any changes
Example:
Component 1 Injects store and changes it, this component has a "watch(store.state, () => {...} )" inside the setup function to see what changed.
Component 1 calls Component 2 using Vue Router **Note that component 2 is not a component 1 child, it is a component in a different route"*
Component 2 Also injects the store and also changes it , the watch on the component 1 doesnt fire
Can someone help me... please?
Do you have at least part of that code you are trying to debug somewhere online?
I understand what you are trying to achieve, but the same thing you said can be implemented in hundred ways. :)
Composition API + XState
awesome :-)
Thanks Ranga!
Still using vuex peristance
Yeah kind of a bummer we can’t do that without quite a bit of extra work.
And what about the modules?
Whaddya mean TrashD?
@@MakeAppswithDanny Can we adapt the vuex modules to this new form?
Pretty simple....make state composable, inject into component, profit.
Heck yeah!
The fact of using Proveiders discourages me. Vuex turns state management simple without main provider on the root.
You don't need to use provide, you could just import the store where needed if you prefer 👍
@@MakeAppswithDanny If so, will be awesome. Have some devtools to debug the states?
@@fagner-sa Hmm I'm not sure how you would debug it if it's just being imported ...
Please share the source code. Thanks
That moment at the end of the video when he says it doesn't work with Vue devtools. 😭
Yeah it's a bummer. Though to be honest, I'm not missing it too much in my app Fudget 2 (where I'm using Composition API for state management).
Still Vuex better and its same as using global context in react but still majority use redux with react and when apollo will support vue3 ?
it's true the composition api is smaller and comfortable, but how about multi `store/` then what ? for example we have vuex for USERS and we have a other vuex for ORDER, in vuex we create two file for each one , but in this way (composition api) is more difficult and I can't understand it . can u (@MakeAppswithDanny) or someone explain it for me ?
You basically just create a separate composable for each store, e.g. create useStoreUsers.js (and add all your user data & methods) then create a useStoreOrders.js composable (and add your order data & methods).