If you have composables in your composables directory, where would you put the non-composables? Would you make .ts files that sit right in the same folder with your .vue SFC files, or would you put them in some other "utils" or "helpers" folder? I find when I often reach for a composable is when my .vue file's script is getting large and I want to offload some larger functions into separate files, or if I find that there's one or more functions my component is using that I want to reuse for other components. I'm also not the biggest fan of having to always prepend "use" - semantically, it often doesn't make any sense to name it "useThing" - so I find myself really not wanting to use that naming convention - even if it has become a common practice. I wish there were a lot more videos on conventions for organization of things, because it feels like - even as much as Nuxt does in choosing sensible defaults and conventions - people still find ways of forging their own path for certain things and ways of organizing their repos and code.
Hey Nathan 👋🏻 I usually put functions that are no composables but should be reused into a `utils` folder indeed - grouping them by "concern". For composables, I mainly go for `use` or. `on` which *should* cover most scenarios. If you have some where it feels "unnatural" or "wrong", I'm curious to know more! Planning some more code organization video, especially at some point when Multi App Support for nuxt lands 🔥
A few more directories I almost always use (that aren’t necessarily standard Nuxt 3) are: /types (for all your .d.ts declared type interfaces) /packages (If your repo is a monorepo, shared package.json devDeps go in here) /config (I like to pull out any huge chunks of nuxt.config and put them in individual config .ts files here)
I always outsource *everything* which doesn't interact with Vue into a script file. Therefore, the Vue files are much shorter and easy to read. My folder structure could look like this: scripts folder: users.js authentication.js dashboard.js todos.js helpers.js composables folder: users.js event-listeners.js ...
@@TheAlexLichter I deal with very project specific issues on daily basis so nothing in particular interests me at the moment. But seeing you go deeper into various Nuxt details by itself would be great
Thank you for a clear and good explanation. I was wondering about that user function that you determined was a composable, and renamed to useUser. That user ref in there, should not that normally be defined outside the function? At least if you want all the users of that composable to share it?
Hey Otto! Thank you for the kind words 🙏🏻 It depends a bit what it is used for, but yes, putting the ref outside would create global state, which can be desired in this case! When using Nuxt though, I'd rather go with useState + keep it inside because that way I create global state without "leaving the Vue context" 😋
@TheAlexLichter great video and a lot of realization with my coding pattern since I'm so used to work on Vue2 options API, now I have a lot of "to do's" for my project's components running in Nuxt 3 that is falling on the checklists 😅 I'm just wondering if you'll declare an lifecycle hooks inside an composable, and declare it of the component/s, would it be hooked/follow on the component's lifecycle? how the lifecycle hooks behave on the composables when it is declared on the component/s? hope that you'll notice this, thanks.
Great explanation and tips Alexander! I'm doing a bit of refactoring now 😅 What about the classes? Should I check the checklist for all methods of the class and, if at least one method acomplish one of the conditions, it means the class is a composable? How would you approach it? Thanks in advance!
To be fair, I almost never use classes as abstraction in the frontend. I'd suggest to make them as "composable-free" as possible and use actual composables to work with classes, e.g. as I've shown with the repository pattern th-cam.com/video/jXH8Tr-exhI/w-d-xo.html
Thank you for this informative video. I think the best name of composables that hold only lifecycle hooks is onX instead of useX, also you forget to add dependency injection in the checklist
Hey Brahim! Good points. I would use the `on` prefix for "reactions", e.g. onKeyPressed or onResumePage, which are not necessarily tied to lifecycle hooks but more as "reaction to changes/state". ☺️ DI is a good point indeed - though that also means dealing with state in a way so I might get away with categorizing it into the "stateful" rule here 😇
One of the rules I miss is re-usability. I see composables like some kind of mixins and composables should only be created when the functionality is re-used, like so for mixins. So I would like to add a rule: Is the function used in multiple places? Correct me if I'm wrong :)
Hey! Yes and no. You can also have composables that are extracted but live in the components (or an extra file) and are not reused, purely for grouping ☺️
That would be more usefully to get some examples of common problems solved by composable. Like for example should i made some of those as a wrapper or maybe a plugin would be better let say for a case when i have to check for 401 every time. Where else composable could make my life easier and just not over complicate an app for no good reason.
Hello, I am coming from your video "You are using useFetch WRONG!", and this is my scenario. I wrote a couple of composables that uses useFetch, which is a real composable(as per this video). Now, some of these composables uses that composable(nested). But I am going back to the problem "Component is already mounted, please use $fetch instead." which will be fixed if I use $fetch. My question is, if I change useFetch to $fetch, does that mean it is not composables anymore? Thanks.
Hi. You said composables can be used in lifecycle hooks. Do you have a good example of this scenario? I feel like composables should compose component only in setup fn or other composables.
I wouldn’t advise it but the *can* in some scenarios (according to the docs) I think I never used it but possibly when working with SSR and depending on window or document - but there are IMO nicer workarounds there
Hi Alex, i have a question. I think i use composables a bit wrong. I use them just for the autoimport sake. For example i have one super simple one that just resolves a promise after a given number of miliseconds. I used them like some helper functions. But the question is, where should i put those files in my nuxt project if not in the composables directory?
Hey Evest 👋🏻 Yes, that's not entirely as intended. You have "utility functions" there which I'd put in the utils folder. These shouldn't have a "use" prefix but are also auto imported! 😋
Same as with JavaScript functions -> a different instance. If you use a ref *outside* of a composable though, it acts as global state. This shouldn't be done when using SSR though (for that you use useState).
Hey! Great video, thanks for it. What do you think about inject? Will it turn function to composable? I think yes because it requires vue injection context
Thanks for that great video which makes it really clear. But I guess there is another question: is your composable a composable or a plugin? Can you help me with this or is it planned for another video? Thanks alot
@@TheAlexLichter it's more a general question referring to your question (util function vs composable). I find myself some time getting stuck in trying to answer to myself is this particular function might be set up as a plugin or a composable. And I think it's not that easy... or Im just overthinking those concepts. A simple example could be: fetching data like products, which are only needed on that particular page, not stored and/or used in other components
// is this a composable? Even though it's a bit silly, I say yes! Technically it has state. const keys: Record = {} export default function (key: string, callback: Function) { if (keys[key] === true) return keys[key] = true callback() }
I'd say it is no composable as managing the state happens through exposing global state and not through reactive references 😋 You can easily run it outside of the Vue context in any browser or Node enviroment 👍🏻
I've always struggled with deciding when something is a composable and when I should be using pinia or something to manage... maybe there is no case for pinia anymore since you technically could do almost all of it with a composable....
Pinia is eventually also a "very refined composable" :D And it still can be valuable, depending on what kind of app you build and what needs you have. Especially plugins, devtools integration, a clear data flow etc. etc. can be pretty helpful for the DX.
I always wanted to learn the difference between a composasble and just utilitiy functions. Thanks! this was super clear.
Glad I could help you out on this 🙏🏻🙌🏻
Damnit, I already see myself next week refactoring a bunch of code...
Haha, I totally understand that 😛
If you have composables in your composables directory, where would you put the non-composables? Would you make .ts files that sit right in the same folder with your .vue SFC files, or would you put them in some other "utils" or "helpers" folder?
I find when I often reach for a composable is when my .vue file's script is getting large and I want to offload some larger functions into separate files, or if I find that there's one or more functions my component is using that I want to reuse for other components.
I'm also not the biggest fan of having to always prepend "use" - semantically, it often doesn't make any sense to name it "useThing" - so I find myself really not wanting to use that naming convention - even if it has become a common practice.
I wish there were a lot more videos on conventions for organization of things, because it feels like - even as much as Nuxt does in choosing sensible defaults and conventions - people still find ways of forging their own path for certain things and ways of organizing their repos and code.
Hey Nathan 👋🏻
I usually put functions that are no composables but should be reused into a `utils` folder indeed - grouping them by "concern".
For composables, I mainly go for `use` or. `on` which *should* cover most scenarios. If you have some where it feels "unnatural" or "wrong", I'm curious to know more!
Planning some more code organization video, especially at some point when Multi App Support for nuxt lands 🔥
A few more directories I almost always use (that aren’t necessarily standard Nuxt 3) are:
/types
(for all your .d.ts declared type interfaces)
/packages
(If your repo is a monorepo, shared package.json devDeps go in here)
/config
(I like to pull out any huge chunks of nuxt.config and put them in individual config .ts files here)
I always outsource *everything* which doesn't interact with Vue into a script file. Therefore, the Vue files are much shorter and easy to read.
My folder structure could look like this:
scripts folder:
users.js
authentication.js
dashboard.js
todos.js
helpers.js
composables folder:
users.js
event-listeners.js
...
Great job, please make these more insightful Nuxt videos
Thank you Marcin 🙏🏻 I'll keep them coming! Is there anything specific you'd like to know more about in the Vue and Nuxt world?
@@TheAlexLichter I deal with very project specific issues on daily basis so nothing in particular interests me at the moment. But seeing you go deeper into various Nuxt details by itself would be great
@marcinnieznaj5666 will put more “nuxt in-depth” content on the list 👍🏻
6:45 , i guess thats why nuxt framework has 2 folders... one for composables.. and other utils for just helper/utility functions... :D
Exactly 👌🏻
Thank you for a clear and good explanation. I was wondering about that user function that you determined was a composable, and renamed to useUser. That user ref in there, should not that normally be defined outside the function? At least if you want all the users of that composable to share it?
Hey Otto! Thank you for the kind words 🙏🏻
It depends a bit what it is used for, but yes, putting the ref outside would create global state, which can be desired in this case! When using Nuxt though, I'd rather go with useState + keep it inside because that way I create global state without "leaving the Vue context" 😋
@TheAlexLichter great video and a lot of realization with my coding pattern since I'm so used to work on Vue2 options API, now I have a lot of "to do's" for my project's components running in Nuxt 3 that is falling on the checklists 😅
I'm just wondering if you'll declare an lifecycle hooks inside an composable, and declare it of the component/s, would it be hooked/follow on the component's lifecycle? how the lifecycle hooks behave on the composables when it is declared on the component/s?
hope that you'll notice this, thanks.
Waiting for the next video, I will always look forward to it, Thank you very much Alexander
Delighted to hear that 🙏🏻 any favorite video so far? ☺️
@@TheAlexLichter everything
This video answer the question I ask the other day on one of your videos, Thanks Alexander
Any time 🙌🏻
You have a hand in the topics which matter the most.
I'm very happy that you think so! 🙏🏻Hope the examples helped understanding when a Vue composable is a composable 😋
Вопросов нет. Всё ясно и понятно. Благодарю 👍
Рад это слышать, приятель 👏🏻
Great explanation and tips Alexander!
I'm doing a bit of refactoring now 😅
What about the classes? Should I check the checklist for all methods of the class and, if at least one method acomplish one of the conditions, it means the class is a composable? How would you approach it?
Thanks in advance!
To be fair, I almost never use classes as abstraction in the frontend. I'd suggest to make them as "composable-free" as possible and use actual composables to work with classes, e.g. as I've shown with the repository pattern th-cam.com/video/jXH8Tr-exhI/w-d-xo.html
@@TheAlexLichter Thanks for the answer! I'll try to follow these suggestion 😊
Thank you for this informative video. I think the best name of composables that hold only lifecycle hooks is onX instead of useX, also you forget to add dependency injection in the checklist
Hey Brahim! Good points. I would use the `on` prefix for "reactions", e.g. onKeyPressed or onResumePage, which are not necessarily tied to lifecycle hooks but more as "reaction to changes/state". ☺️
DI is a good point indeed - though that also means dealing with state in a way so I might get away with categorizing it into the "stateful" rule here 😇
@@TheAlexLichter thank you for reply
One of the rules I miss is re-usability. I see composables like some kind of mixins and composables should only be created when the functionality is re-used, like so for mixins. So I would like to add a rule:
Is the function used in multiple places?
Correct me if I'm wrong :)
Hey! Yes and no. You can also have composables that are extracted but live in the components (or an extra file) and are not reused, purely for grouping ☺️
That would be more usefully to get some examples of common problems solved by composable. Like for example should i made some of those as a wrapper or maybe a plugin would be better let say for a case when i have to check for 401 every time. Where else composable could make my life easier and just not over complicate an app for no good reason.
"The mouse on the page" got me real good 🐁
Haha, glad you spotted and liked that 😁
Thanks for the video. what about using composables as service layer (fetching data) and then using it in setup? Will it breach convention?
If you handle the state (think of sth like useFetch) it is fine
If it is just a fetch function (like the Fetch API or $fetch), it would be a utility!
Hello, I am coming from your video "You are using useFetch WRONG!", and this is my scenario. I wrote a couple of composables that uses useFetch, which is a real composable(as per this video). Now, some of these composables uses that composable(nested). But I am going back to the problem "Component is already mounted, please use $fetch instead." which will be fixed if I use $fetch. My question is, if I change useFetch to $fetch, does that mean it is not composables anymore? Thanks.
Using a nested composable seems fine. The question is where the top-Level composable itself is called 👀
@@TheAlexLichter I get it, I found out that the warning was caused by watchEffect(), because it is executed twice on a direct page load.
Hi. You said composables can be used in lifecycle hooks. Do you have a good example of this scenario? I feel like composables should compose component only in setup fn or other composables.
I wouldn’t advise it but the *can* in some scenarios (according to the docs) I think I never used it but possibly when working with SSR and depending on window or document - but there are IMO nicer workarounds there
Hi Alex, i have a question. I think i use composables a bit wrong. I use them just for the autoimport sake. For example i have one super simple one that just resolves a promise after a given number of miliseconds. I used them like some helper functions. But the question is, where should i put those files in my nuxt project if not in the composables directory?
Hey Evest 👋🏻
Yes, that's not entirely as intended. You have "utility functions" there which I'd put in the utils folder. These shouldn't have a "use" prefix but are also auto imported! 😋
Thanks alot Alex! Greets from Düsseldorf
My pleasure! Greetings back from AMS 🙌🏻
Thanks, after reading the docs I couldn't see the difference, now I do
Glad I could help 🙌🏻
This helped me so much thanks 🙏
Happy to hear that! You are welcome 🙌🏻
Question! if 2 component calling the same composable, did it create different instance of that composable or they are sharing the stateful value?
Same as with JavaScript functions -> a different instance.
If you use a ref *outside* of a composable though, it acts as global state. This shouldn't be done when using SSR though (for that you use useState).
Hey! Great video, thanks for it. What do you think about inject? Will it turn function to composable? I think yes because it requires vue injection context
Yes! Definitely also a composable - provide/inject is another way for handling state so that counts too 👌🏻
Thanks for that great video which makes it really clear.
But I guess there is another question: is your composable a composable or a plugin?
Can you help me with this or is it planned for another video?
Thanks alot
Hey! Interesting - Do you have an example where it is rather unclear?
@@TheAlexLichter it's more a general question referring to your question (util function vs composable). I find myself some time getting stuck in trying to answer to myself is this particular function might be set up as a plugin or a composable. And I think it's not that easy... or Im just overthinking those concepts.
A simple example could be: fetching data like products, which are only needed on that particular page, not stored and/or used in other components
@The4tticuz I’d mostly go for a composable in this case. A plugin is useful if you need to provide a „global helper“, eg a custom $fetch instance 👍🏻
// is this a composable? Even though it's a bit silly, I say yes! Technically it has state.
const keys: Record = {}
export default function (key: string, callback: Function) {
if (keys[key] === true) return
keys[key] = true
callback()
}
I'd say it is no composable as managing the state happens through exposing global state and not through reactive references 😋
You can easily run it outside of the Vue context in any browser or Node enviroment 👍🏻
I've always struggled with deciding when something is a composable and when I should be using pinia or something to manage... maybe there is no case for pinia anymore since you technically could do almost all of it with a composable....
Pinia is eventually also a "very refined composable" :D
And it still can be valuable, depending on what kind of app you build and what needs you have. Especially plugins, devtools integration, a clear data flow etc. etc. can be pretty helpful for the DX.
Thanks for the info. Very clear.
Glad it was helpful!
If my composable has global state in Nuxt 3 or uses say a pinia store would that make it a composable?
Yes, absolutely!
why am I able to use the useFetch composable inside a util function in /utils directory?
Nobody "formally" restricts you to use it in `utils` *but* your "util" is then a composable. So it is not correct 😋
8:10 , if u didnt know computed is also ref , u only mention user as stateful logic... eventho computed is not ment to be mutated/create side-effects
If you have a computed in a composable, then somewhere in there should also be a ref 👀
Can be as input or as initialized variable ☺️
Clear as mud sir! Just kidding
😜
Hope it helped ☺️
@@TheAlexLichter I kind of khew them but how you put that into 3 simple rules was super clear.