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 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 😇
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.
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" 😋
// 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 👍🏻
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 ☺️
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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jXH8Tr-exhI.html
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 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
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
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 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! 😋
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
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).
