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!
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.
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?
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. 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.
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! :)
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 :-)
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.
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 }
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.
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 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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-OluD-GW8cRM.html
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 !!!
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.
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 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
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
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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-JGC7aAC-3y8.html
@@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.
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.
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
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 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/
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"
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.)
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.
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). 👍
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 👍
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 💩🍌😂
@@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 :)
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
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?
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
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..
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.
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....
@@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 👍
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.
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).
