Wow! This should be a must watch for old heavy vue 2 users (like myself). I am jumping right away into some heavy refactoring! Thanks a lot Alex! Your videos are absolutely great. P.S. Loved the inline-composable concept!
I was getting ready to comment "do we really need a composable for one logic in a component". but the video shows just exactly what you need from nuxt. Thanks Alexander
This is all great stuff and you are also improving on your way of presenting all of this. I really enjoy these videos! Also as a suggestion coming from working in bigger companies and aligning with some other questions asked below, it would be a very nice idea if you can create videos on common scenarios like indeed how to deal with filtering, pagination, structuring API routes, access control and maybe even CI/CD etc :) All the best man. Learning a lot and catching details I wasnt aware off!
Thank you Chris! Noted the "common scenarios" idea, especially when ti comes to pagination, filtering (URL state one the list already), API structure etc ☺ I appreciate the kind words and support 💚
I really like these kinds of 'Practical Example' videos that can be applied to real-life scenarios. I suggest making some short code review videos as well.
Thank you for the great content! I have to admit I made this mistake when I started with Vue3 composition API, but as soon as I started using composables, the way you show in the video makes much more sense!!
Interesting concept, I can see that really helping with larger files that you want to organize but don't want in multiple files. As usual, great video!
Thanks Josh! Yeah, especially in bigger projects (hard to showcase in ~15 minutes) they are helpful due to all the different concerns a single component might have 👌
Nice Video Alex! I just came across a article a few weeks ago from Michael Thiessen on these inline components and was working on a video about them. I've used these quite a bit in my application recently. Definitely find code a lot more organized.
Thank you John! I totally missed Michael's article on that and noticed it is almost a year old. 😲 Crazy! Same, I use them where applicable in various projects and am really happy with the code readability and maintainability ✔
For sure. I think anyone who comes from Vue 2 and Options API will take some time to "unlearn what they have learned" in terms of organizing in the Options fashion, even with Composition API. Inlining your composable makes a lot of sense if nothing else will use it - and that's a common question we ask ourselves - what other components will actually use this code? Sometimes it's hard to not think of composable as only reusable code, so this might be a refactor in reverse, where there might be composables only used by one component that are better off inlined. Great stuff as always Alex!
Never did this, I'm a disciplinary person. But, I'm the only one right now programming in nuxt 3/composition api at my team. Will share this video with my team members though as they will use nuxt 3 in the near future as well 👍🏻
@NathanCase Yes, absolutely. That's what "we" were used to for long. I did the same in the beginning 😊 The point you talk about - is function XYZ reusable is exactly the point - and now people have the choice to refactor without making things "automatically reusable" but still having an easy way to organize code by concern but still grouping things closely together + a simple way to make it reusable if necessary 👌
Love this! I'm still getting used to the composition API and I'm guilty of structuring my code in the options way. Going to refactor some stuff now following the same line of thinking you showed here.
This video was the best I have seen about Vue. Although I have a small query, if I instantiate a composable globally inside a , can I use it inside a 'Reusable functions specific to this component' without importing it internally? Or must the composable be instantiated again internally.
You technically can reuse it as it was instantiated beforehand 👌 But I probably would be explicit if it is a composable. If it is a plain *function* though, you can just re-use it without issues.
Fire video - definitely like the part about inline composables. One thing I've seen is how defineProps/defineEmits is the one part where the composition API kinda forces the grouping by "options" - do you think grouping all the defineProps/defineEmits/defineModel at the top of the component is still the best approach? I've seen defineProp single use macros in Vue Macro/RFCs but don't know how I feel about it yet.
Yeah, for macros it is a bit tricky. I try to keep props at the top and then use them where needed. If I need prop-refs, I convert them where needed. For emits, I also define it at the top. Both of them are fine there IMO defineModel should (and can) be moved as close to related code as possible 👌
Very well explained! Thank you 😊 Here is the idea for the video: Keeping the state in the URL. How to handle states like pagination or such using url queries. Would love to get a tip or two in that space! Or if you know some good articles.
Thank you! Believe it or not, it is up high on my list as I see lots of mistakes around that. Even discussed some helpers for Nuxt (github.com/nuxt/nuxt/pull/24369)!
I love your videos! Can you make a video about using generic components? I know it's not Nuxt, but would love to see someone tackle this feature. Perhaps even show real world advanced use cases. Would love to hear from you! Thank you for all your hard work!!
I like the idea of inline composable but how I should test my logic business inside at my composable if it inside my component? I always love divide business logic and view but if I keep it all together how I should do it
That depends on the logic. You can always extract the logic itself into a function and test it if it is used in multiple places. Otherwise, why not testing the component itself?
Hi. I recently used Nuxt 3 in one of my projects and what I couldn't realize that how can I wrap my code in a package that helps me to organize it without going on option apis way. Thanks for sharing your thaughts!🤘
I like it, even tried to implement it in one of components in our project, however I have one question not quiet related with it. We are using eslint and @typescript-eslint/explicit-function-return-type rule, so I need to have return type for all the composables/inline composables, they can change very often and typescript can infer their type very reliably. Do you have any suggestions on how to get around the rule or any tips on how to define return type for composables?
I think having an explicit return type for composables is not a bad idea (at least for "mature" parts of the application). You can provide types as usual (see play.vuejs.org/#eNq1VV1vmzAU/Su3vIRIKZlU7SWj1bo1UjepW5V2mybxwsCAW2Ij2ySZsvz3XRsbCE3a7mFSP8D33O/D8da7rKpgVRNv5oUyEbRSIImqKyhjlp9HnpKRdxExuqy4ULAFQbIJJHxZ1YqkE1jHKikmoH5XBBbapLj599Ei8AV2kAm+hBFmGUUsYtMp3BAp45ycClLGiAKp6iyLWMKZVMAFzSmLSwuCc53UH12TsuTwg4syPRmNHXiLGfO8JAuyIkKSCSyt1w79aklsEH8QFP1NIfdko05lwdcMVEFZLl1cKu/MaZM8i0upfZxtEbOUL7XzIZQZim8jTMBnZP09LmsyhvML2EYMnkYIVhqAcUwMA8nAP+k8jRtgGlULLB1g50A3sSoCYcL5YwjhTfD2KPxoWiVqzLprx/Lzdn4Hl1dX8yu4ni/m+tjs+Fs70YUJja4m1d4SZoCFYKsrTtOJttqdzPq0CKUSOHDkFpYWsaxmiaKc9XdGGYJnmlcODH+QKvppPHtaiinkGIUML5uI2KTDiabgtMM5avtNC4NAzbwCWZVU+aPROLAB/HHwwCnTR73oOG4bf0AQgLbdvcFhTru4zrVd0cnwrF1rk80R/0kPLiRyZRiizeeoMpxIl8nmaoEHJ2NKMiRqcTbB/lfanNmKbR/4E04bCUJS4Isiy0rLA74BhGZ1sDpd8pSUKEyD/JEH0wb4q1YKB/s+KWnyiMDuS8YJmkdUtHtTTjhtwIcd90pGH/u075TSFRZFsy6R0Uvd3nbbiZGZXThF9AG3wUfZBrgvqIQilhBDUsQsIfDOkMfFCae9EXkT1GpkQkbz4EFyhoJuRh95mg60JOJrpRmHej5zS4m8GDV1/dmcaQmwi0GfgiSPB84f5EafRd6tIJKIFc6ltalY5EQ15vndF2ynZ8S11SWinzEuiORlrWtsYB9qlmLZPZyp9pO5ilAD7uV8owiTrqlGw5BLBh95eN9ovTnWelfuWXDmOIhT7AQoUBKneOzqG9x5+9ecQAbjL9kY338VNywSnV8pZj3kf5GzXvxjgmYgz0iasb9S1Ax218/6jLC5wEekzZpfEDeLsjlfELimPNNy89zKnPUeCJ09dVLXdWf+eLu/K2RHYA==, but I would also think of disabling the rule if they change too fast, as it only concerns a single component. "It depends" sadly 🙈
I would not organize by name but would give "more expressive names". So e.g. say `isMessageReversed` - absolutely! Still keeping them in an inline composable though :D
When refs, computed, watchers... used across different parts of logic, then where put it? Also props and store and some composables will be composition style anyway. So mixing top level things and logic related?
great content as always! have you made any video about Nuxt lifecycle? coming from Nuxt 2, i was a bit surprised knowing that now plugin comes before middleware. Nuxt 3 doc seems to not mention this change. Also the doc no longer have any lifecycle diagram, cmiiw.
I'm used to pack stuff like option api because I find it convenient (also composition is by itself less verbose code). I don't need to read the code to figure out where are the variables among functions, watchers and so on, figure out lifecycle called code, etc; they are all packed together. But that's true when the file get big it make me jump middle-top-middle often, or I have to collapse everything. I will try to separate by logic to see what happens but just the idea of mixing stuff make me uncomfortable. Also wasn't expecting the "spaghetti code" splash but ok.
IMO it is just a matter of getting used to it. And as you mentioned - you rarely look for "where are the computeds" but most of the times "where is the related code". And if that sticks all together, it is easier to find then jump from top to bottom to the middle (as you mentioned as well). Uncomfortable !== bad. Definitely try it out and see how it goes 👌
Ignore the complainers, video is fine. Interesting approach; I love composables but tend to avoid them because the devs I work with don't have time to navigate multiple files. Inline approach could be the answer 👍
What's the reason of keeping originalMessage outside useMessage? If it is only used inside the composable, we can put it inside so passing it to useMessage is not needed right? Or I'm missing something?
If you eg want to hook up originalMessage via v-model to an input field and then pass in the composables (or anything else, so you make it more flexible). But you don’t need to if there is no case for it 👌🏻
I don't really see the advantage of the "inline composable" at least not in this example. Like what is won in the end from wrapping the logic in the function useMessage, if it is only used in one place? Why not just have the reversedMessage computed and the toggleReverse function as they are in the component? I'm pretty new to vue3 and composition so just trying to learn. Interesting video though :)
Thanks for the feedback! This is a super small example of course. But think of a larger component that you can't split into smaller ones with more logic. Then, it helps a lot to group them by logic instead of just "writing them down imperatively"
Hey great video! One topic I would love if you could cover is the usage of the same component for creating something( like a user creation modal with a form) and editing the same thing with the same component(same modal that opens prefilled with the selected user form). What would you say is a good approach here?
Thank you 🙏 Yeah, I think you can always extract them later if you want to reuse them, but before it might simply be a premature abstraction / optimization.
Of course! Both, the original and refactored version are linked in the Vue Docs - vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization No color coding though
But if you use inline composables, i think we will loose the power of separating logic from the components while doing the component test What do you think?
Yes and no, because: 1) If you test components, I wouldn't test implementation details but input and outputs. 2) You can always extract business logic without extracting the composables (if necessary)
@ I agree it’s a trade off. But my personal style is to create folder trees with meaningful naming instead of creating a single big fat file. Maybe because I wasn’t able to afford multiple big screens when I was learning to code.
Am I the only one who gets error like "Block-scoped variable 'useComponentComposable()' used before its declaration.ts-plugin()" ? It's strange that on video there is no error
Do you have an example of code (e.g. a playground link)? Normal functions do not need to be declared before used (hoisting) but arrow functions and variables holding fn's (const abc = function(){}) do.
@@TheAlexLichter I remember how 20 years ago at the university we were taught OOP and encapsulation, and even then it was something ancient and 101 😏 But I agree: It's better to reinvent the wheel than to drive without a wheel at all 😅
Well luckily we don’t need OOP in the front end nowadays. IMO it is great in the backend (to some degree) but horrible in the front end. I’ve also learnt it in Uni 😁 But encapsulation can be done so nicely, and luckily the Composition API doesn’t force us to group by „type“ anymore 🙏🏻
@@TheAlexLichter "Well luckily we don’t need ~~OOP~~ WHEELS in the front end nowadays" - yep, let's just reinvent them 😂😂😂 It might be funny if it wasn't so sad, thb Have to work with Vue/Nuxt for last months... And every time I wander how awful it is from the design point of view 😢 The worst thing is that it encourages devs to write bad code - without encapsulation, with duplication and lots of boilerplate The interesting fact that most of the problems that frontend Vue/React/... devs are fighting so "heroically" now, were obvious from the VERY beginning While frontenders were desperately fighting against jQuery, mobile devs managed to emerge, grow and even mature: they re-invented Clean-Architecture, design patterns, etc. 😅 But nvm, just a cry from the heart... Anyway, thanks for the video, and have a good day ?? night 😉
"...even in general. If you write a comment to describe stuff, why not write a function, instead of a comment..." Sorry Alex, but this sounds to me like you haven't seen really large projects with really complex and convoluted logic.
Oh believe me, I’ve seen enough weird code 😁 Also, to avoid misunderstanding: nobody stops you from writing JSdocs/TSDocs for your functions (which I definitely encourage). But instead of having one 1000 LOC function, writing subfunctions is the obvious way ☺️
I want to follow what the authorities suggest but I'm still unconverted. Nothing I've seen about Composition API including this video makes me prefer it over Options API. I want structure by aspect of component, not by function; for that shouldn't I create a child component? Also, I don't want every line beginning with "const" and looking the same. I notice too that even old-hand Composition API people keep forgetting to append ".value" after every variable, which is a drag and a case where a bit of magic might remain a good thing.
GOD I hate redundant variable prefixes. Both shown and reversed are already terms defining a binary state! lol Outside of that, what you're basically advocating for here is vue controllers :)
I'd say they add info. See this example: show method vs. show boolean reverse method vs. reverse boolean Not really clear IMO show method vs. isShown boolean reverse method vs. isReversed boolean More clear when reading ;)
In most cases I find adding prefixes is a symptom of not thinking through the domain language appropriately, usually a sign of lazy thinking. Not saying you are, just been my experience running a software firm and managing lots of engineers :)
To me, suffixes like "String", "List" etc. (think of userList, identityString) are in line with what you mentioned. The "is"/"has"/"does" prefix is different because it doesn't describe the word but more the action that is triggered by the boolean. Also isShown, willShow, hasShown, can all have different info, which is another reason why I am in favor of it for booleans
@@TheAlexLichter It's a good argument but one I still fundamentally disagree with. Suffixes as you mention, I agree - they're redundant, and I advise my team not to use them as well. You don't need the prefix to advertise intent, as that can come from both the method/function signature, as well as its use, eg: if (this.reversed()) reads identical to if (this.hasReversed()). You can't use reversed() in any other context, it's a question about the object's state in the example I provide, and the engineer's intent is already clear. Regarding your last example, the only one that stands out is willShow, as this is a question about future state, rather than current state, and in that case it probably does make sense for the given context. This is obviously different from canShow, which is a question about potential state, which could also be reworded as "showable()". Hope that makes sense - and good discussion :)
Tbh, in the end the code still looks awful 😭 Please add at least blank lines before functions so that the code doesn't look like auto-generated sheet that no one is going to read 😖
Exactly, you will write lots of functions which contain all the related logic at one spot and even give a descriptive name to it. Which approach would you prefer otherwise? 👀
@@TheAlexLichterI will have to experiment with this. Maybe it is better indeed. The way I am doing it at the moment is exactly what you suggested NOT to do in the beginning, where I group them in a similar way to options api…
@zlatkoiliev8927 definitely give it a try! It will take a bit to get used to but it’ll feel way better to have things grouped by logic, like you’d do in classic JS/TS files too! ☺️
how is nobody talking about the incredible annoying white box glitches through out the whole video? is this another case of js dev just accepting anything as is?
Nope, sorry, your advice may work for smaller apps of maybe only 200 or 300 files.. but once you get to the couple of hundred thousand files, you will shoot yourself in the foot.. There are advantages to keeping everything grouped by options.. Once you have started to work on bigger projects, you may start to learn this for yourself.
Hey Colin! I’ve worked in projects definitely beyond the 200-300 files mark and there, grouping by logic actually helped understanding what is going on faster than everything grouped by options! Why you may wonder? Because the code was easier to read and understand than when it would’ve been grouped by options because you don’t have to jump through the whole file 😊 So I think the other way around it is 👌🏻 Grouping by options is the “footgun” for bigger files and projects!
@@TheAlexLichter good luck with that then.. Maybe when your projects get bigger and your teams get more diverse, you will see how it starts to make things worse.. Don't worry, you will get there..
I have no problem agreeing to disagree. Nobody has to take any of the advice I am giving here - and actually it’s good to draw own conclusions. But I would appreciate not being treated like I am new to the game and “will get there” 😊
@@TheAlexLichter Sorry you feel that way, I am just trying to help you not get stuck in a rut of what you believe now. This will help when you start to work on bigger projects with more diverse teams.. You don't need to take any of the advice. Just trying to help you as you grow.
Then bring on some arguments or leave it 😁So far you said "there are advantages" and listed none. You talk about gigantic project and diverse teams but still listed nothing speaking in favor of grouping by option! Curious for your thoughts (without patronizing plz!)
Bruv, this was exactly what I was looking for! My setup was getting pretty confusing
Glad to hear you found the video then 🙌
The idea of inline composable is very helpful !
Thanks Johnson! Hope you'll use them 😋
Wow! This should be a must watch for old heavy vue 2 users (like myself).
I am jumping right away into some heavy refactoring!
Thanks a lot Alex! Your videos are absolutely great.
P.S. Loved the inline-composable concept!
You are welcome Antonio! As a heavy Vue 2 user myself, I can definitely relate and hope it helps everyone who is coming from the Options API 😊
I was getting ready to comment "do we really need a composable for one logic in a component". but the video shows just exactly what you need from nuxt. Thanks Alexander
You are welcome! 🙌
This is all great stuff and you are also improving on your way of presenting all of this. I really enjoy these videos! Also as a suggestion coming from working in bigger companies and aligning with some other questions asked below, it would be a very nice idea if you can create videos on common scenarios like indeed how to deal with filtering, pagination, structuring API routes, access control and maybe even CI/CD etc :)
All the best man. Learning a lot and catching details I wasnt aware off!
Thank you Chris! Noted the "common scenarios" idea, especially when ti comes to pagination, filtering (URL state one the list already), API structure etc ☺
I appreciate the kind words and support 💚
Nice video! But the blinking in the top while screen recording is pretty annoying... maybe you can fix that for future videos.
Yes, sorry for that. Was the first and last time that happens, misconfigured recording settings. 🙈
I really like these kinds of 'Practical Example' videos that can be applied to real-life scenarios. I suggest making some short code review videos as well.
Thanks! I might do these on stream and release a VOD here 👌
Thank you for the great content! I have to admit I made this mistake when I started with Vue3 composition API, but as soon as I started using composables, the way you show in the video makes much more sense!!
Really happy that my content is useful 🙌
Yeah, I also did the same for a bit because I was used to it but eventually overcame it 🙏
I always had this confusion on how to organise code while using composition API. Thanks a lot for this, very helpful video.
You are very welcome 🙏🏻
Interesting concept, I can see that really helping with larger files that you want to organize but don't want in multiple files. As usual, great video!
Thanks Josh! Yeah, especially in bigger projects (hard to showcase in ~15 minutes) they are helpful due to all the different concerns a single component might have 👌
Nice Video Alex!
I just came across a article a few weeks ago from Michael Thiessen on these inline components and was working on a video about them. I've used these quite a bit in my application recently. Definitely find code a lot more organized.
Thank you John! I totally missed Michael's article on that and noticed it is almost a year old. 😲 Crazy!
Same, I use them where applicable in various projects and am really happy with the code readability and maintainability ✔
Did you ever wrote a "// props" comment (or similar)? 🧐
For sure. I think anyone who comes from Vue 2 and Options API will take some time to "unlearn what they have learned" in terms of organizing in the Options fashion, even with Composition API. Inlining your composable makes a lot of sense if nothing else will use it - and that's a common question we ask ourselves - what other components will actually use this code? Sometimes it's hard to not think of composable as only reusable code, so this might be a refactor in reverse, where there might be composables only used by one component that are better off inlined. Great stuff as always Alex!
Never did this, I'm a disciplinary person. But, I'm the only one right now programming in nuxt 3/composition api at my team. Will share this video with my team members though as they will use nuxt 3 in the near future as well 👍🏻
@NathanCase Yes, absolutely. That's what "we" were used to for long. I did the same in the beginning 😊
The point you talk about - is function XYZ reusable is exactly the point - and now people have the choice to refactor without making things "automatically reusable" but still having an easy way to organize code by concern but still grouping things closely together + a simple way to make it reusable if necessary 👌
@Tarabass Discipline helps a lot there! Thanks for sharing it in the future! Let me know if there are any remarks 👍
Great video again, Alexander. Thx for the heads up on structure the code this way.
And congrats with your channel! You're growing fast 🎉
Thank you Peter! Happy that you enjoyed it 🙏
Trying my best to put out the best content I can + being consistent ✌
Love this! I'm still getting used to the composition API and I'm guilty of structuring my code in the options way. Going to refactor some stuff now following the same line of thinking you showed here.
Yess, glad you like it! 🙏🏻
Hope the refactor will go well 🔥
This video was the best I have seen about Vue. Although I have a small query, if I instantiate a composable globally inside a , can I use it inside a 'Reusable functions specific to this component' without importing it internally? Or must the composable be instantiated again internally.
You technically can reuse it as it was instantiated beforehand 👌
But I probably would be explicit if it is a composable. If it is a plain *function* though, you can just re-use it without issues.
This video introducing the composable function gave me a new idea on how to organize my code. thx
Glad I could help! 🙌🏻
Your videos are super helpful for me migrating a project from Nuxt 2 to Nuxt 3. Thanks for the tips
Glad I could help! If you have any other questions or topics you are curious about, let me know ☺️
Very useful, please keep sharing those types of tips 🎉🎉
Thank you, I will! 🙏✨
You should continue doing content on youtube, so little quality content related to Vue on UA-cam.
Great video!
Thanks! That's the plan! Once a week (except specials and streams) - release every Friday 👌
Glad to hear that@@TheAlexLichter
Fire video - definitely like the part about inline composables. One thing I've seen is how defineProps/defineEmits is the one part where the composition API kinda forces the grouping by "options" - do you think grouping all the defineProps/defineEmits/defineModel at the top of the component is still the best approach? I've seen defineProp single use macros in Vue Macro/RFCs but don't know how I feel about it yet.
Yeah, for macros it is a bit tricky. I try to keep props at the top and then use them where needed. If I need prop-refs, I convert them where needed. For emits, I also define it at the top.
Both of them are fine there IMO
defineModel should (and can) be moved as close to related code as possible 👌
Very well explained! Thank you 😊
Here is the idea for the video: Keeping the state in the URL. How to handle states like pagination or such using url queries. Would love to get a tip or two in that space! Or if you know some good articles.
Thank you! Believe it or not, it is up high on my list as I see lots of mistakes around that. Even discussed some helpers for Nuxt (github.com/nuxt/nuxt/pull/24369)!
Very nice Alexander :)
Thank you Guillaume! Hope you'll use the inline composables ✌
Thanks a lot, Alexander! The content is instantly applicable.
Have only one comment, that blinking rectangles in the upper part are a bit distracting.
Thank you for the feedback! It sadly was a recording accident noticed too late. Was the first and last time that happens 👌🏻
I love your videos!
Can you make a video about using generic components? I know it's not Nuxt, but would love to see someone tackle this feature. Perhaps even show real world advanced use cases. Would love to hear from you! Thank you for all your hard work!!
Thanks a lot 🙏
Great suggestion! I've wrote it up the list 👌
This is huge! Can't wait to present this approach to my team
Let me know how your team liked it!
Wow 🤯 now i know where to start and hiw ro "clean" it
Amazing thank you
Happy to help! 👌
Interesting concept! Thaanks so much Alex
My pleasure!
I like the idea of inline composable but how I should test my logic business inside at my composable if it inside my component? I always love divide business logic and view but if I keep it all together how I should do it
That depends on the logic. You can always extract the logic itself into a function and test it if it is used in multiple places. Otherwise, why not testing the component itself?
Hi. I recently used Nuxt 3 in one of my projects and what I couldn't realize that how can I wrap my code in a package that helps me to organize it without going on option apis way. Thanks for sharing your thaughts!🤘
Hey! Great the you use Nuxt 3 now! Enjoy it 😊
And happy that my video could help you organizing the code better!
I like it, even tried to implement it in one of components in our project, however I have one question not quiet related with it. We are using eslint and @typescript-eslint/explicit-function-return-type rule, so I need to have return type for all the composables/inline composables, they can change very often and typescript can infer their type very reliably. Do you have any suggestions on how to get around the rule or any tips on how to define return type for composables?
I think having an explicit return type for composables is not a bad idea (at least for "mature" parts of the application). You can provide types as usual (see play.vuejs.org/#eNq1VV1vmzAU/Su3vIRIKZlU7SWj1bo1UjepW5V2mybxwsCAW2Ij2ySZsvz3XRsbCE3a7mFSP8D33O/D8da7rKpgVRNv5oUyEbRSIImqKyhjlp9HnpKRdxExuqy4ULAFQbIJJHxZ1YqkE1jHKikmoH5XBBbapLj599Ei8AV2kAm+hBFmGUUsYtMp3BAp45ycClLGiAKp6iyLWMKZVMAFzSmLSwuCc53UH12TsuTwg4syPRmNHXiLGfO8JAuyIkKSCSyt1w79aklsEH8QFP1NIfdko05lwdcMVEFZLl1cKu/MaZM8i0upfZxtEbOUL7XzIZQZim8jTMBnZP09LmsyhvML2EYMnkYIVhqAcUwMA8nAP+k8jRtgGlULLB1g50A3sSoCYcL5YwjhTfD2KPxoWiVqzLprx/Lzdn4Hl1dX8yu4ni/m+tjs+Fs70YUJja4m1d4SZoCFYKsrTtOJttqdzPq0CKUSOHDkFpYWsaxmiaKc9XdGGYJnmlcODH+QKvppPHtaiinkGIUML5uI2KTDiabgtMM5avtNC4NAzbwCWZVU+aPROLAB/HHwwCnTR73oOG4bf0AQgLbdvcFhTru4zrVd0cnwrF1rk80R/0kPLiRyZRiizeeoMpxIl8nmaoEHJ2NKMiRqcTbB/lfanNmKbR/4E04bCUJS4Isiy0rLA74BhGZ1sDpd8pSUKEyD/JEH0wb4q1YKB/s+KWnyiMDuS8YJmkdUtHtTTjhtwIcd90pGH/u075TSFRZFsy6R0Uvd3nbbiZGZXThF9AG3wUfZBrgvqIQilhBDUsQsIfDOkMfFCae9EXkT1GpkQkbz4EFyhoJuRh95mg60JOJrpRmHej5zS4m8GDV1/dmcaQmwi0GfgiSPB84f5EafRd6tIJKIFc6ltalY5EQ15vndF2ynZ8S11SWinzEuiORlrWtsYB9qlmLZPZyp9pO5ilAD7uV8owiTrqlGw5BLBh95eN9ovTnWelfuWXDmOIhT7AQoUBKneOzqG9x5+9ecQAbjL9kY338VNywSnV8pZj3kf5GzXvxjgmYgz0iasb9S1Ax218/6jLC5wEekzZpfEDeLsjlfELimPNNy89zKnPUeCJ09dVLXdWf+eLu/K2RHYA==, but I would also think of disabling the rule if they change too fast, as it only concerns a single component. "It depends" sadly 🙈
Great video and clean real-world problem solvent.
Thanks 👍 Glad it helped!
what’s the shortcut for renaming all similar words simultaneously?
CTRL + SHIFT + L (on win) for selecting all occurrences. I usually do CTRL + D (which is select *next* occurrence in addition to the current ones)
excellent content as always!
Thank you Pedro 🙌 Glad you still enjoy the content ☺
Thanks Alexander. That was really helpful.
Glad it was! 🙌
Any reason for passing the original message in as a parameter to the composable? seems like you could just define it in the composable and return it.
You can in this case, of course! It was more to show how you can pass it in in case it comes from other composables or as prop (+ toRef) ☺️
Can you organize by name also? For mesageOriginalText etc. the thing ia tomorrow you might not remember what isReverased reverses.
I would not organize by name but would give "more expressive names". So e.g. say `isMessageReversed` - absolutely! Still keeping them in an inline composable though :D
Very useful video, please upload quality content like this more❤
Will do! Next video coming up today 🙌
When refs, computed, watchers... used across different parts of logic, then where put it?
Also props and store and some composables will be composition style anyway.
So mixing top level things and logic related?
“Above” the composables that use it together, but still as close as possible (so they are co-located)
@@TheAlexLichter Thanks for answer.
great content as always!
have you made any video about Nuxt lifecycle? coming from Nuxt 2, i was a bit surprised knowing that now plugin comes before middleware. Nuxt 3 doc seems to not mention this change. Also the doc no longer have any lifecycle diagram, cmiiw.
Thank you 🙏🏻
Great idea! I helped with the v2 lifecycle page actually so could be a nice case
I'm used to pack stuff like option api because I find it convenient (also composition is by itself less verbose code). I don't need to read the code to figure out where are the variables among functions, watchers and so on, figure out lifecycle called code, etc; they are all packed together. But that's true when the file get big it make me jump middle-top-middle often, or I have to collapse everything. I will try to separate by logic to see what happens but just the idea of mixing stuff make me uncomfortable.
Also wasn't expecting the "spaghetti code" splash but ok.
IMO it is just a matter of getting used to it. And as you mentioned - you rarely look for "where are the computeds" but most of the times "where is the related code". And if that sticks all together, it is easier to find then jump from top to bottom to the middle (as you mentioned as well). Uncomfortable !== bad. Definitely try it out and see how it goes 👌
Imagine you have a large file with 1k+ lines of code you inherited from other dev... Not so convenient anymore
@hangor3620 Exactly, that's the time where grouping by logic will shine!
Very helpful video, bro. Thank you so much! This knowledge is what I found so long ago.
You are welcome! Not a "new pattern" per se, right. But lots of people don't know about it!
GREAT content again! Thanks a lot
Glad you liked it! 🙌🏻
Ignore the complainers, video is fine.
Interesting approach; I love composables but tend to avoid them because the devs I work with don't have time to navigate multiple files.
Inline approach could be the answer 👍
Thanks 🙏🏻
Let me know how your time likes it!
is just me or parts of the video are glitching?
Sadly not just you. A little mistake with the recording settings - won't happen again!
Luckily no code is hidden or obstructed
What's the reason of keeping originalMessage outside useMessage? If it is only used inside the composable, we can put it inside so passing it to useMessage is not needed right? Or I'm missing something?
If you eg want to hook up originalMessage via v-model to an input field and then pass in the composables (or anything else, so you make it more flexible).
But you don’t need to if there is no case for it 👌🏻
Very helpful. I think I'll switch to this approach.
Glad to hear! Let me know how this works out for you ☺️
I don't really see the advantage of the "inline composable" at least not in this example. Like what is won in the end from wrapping the logic in the function useMessage, if it is only used in one place? Why not just have the reversedMessage computed and the toggleReverse function as they are in the component? I'm pretty new to vue3 and composition so just trying to learn. Interesting video though :)
Thanks for the feedback! This is a super small example of course. But think of a larger component that you can't split into smaller ones with more logic. Then, it helps a lot to group them by logic instead of just "writing them down imperatively"
Hey great video! One topic I would love if you could cover is the usage of the same component for creating something( like a user creation modal with a form) and editing the same thing with the same component(same modal that opens prefilled with the selected user form). What would you say is a good approach here?
Thanks a lot! Also a great suggestion for a topic, added it to the list 👌
this is good idea, i use to use third method, sometims use second one, but i try use fourth , it is better for reading code later,thanks
My pleasure! Yeah, inline composables really help structuring the code 🔥
Nice video dude, composable are very usefull even more in same file, i only use it when the component is short
Thank you 🙏
Yeah, I think you can always extract them later if you want to reuse them, but before it might simply be a premature abstraction / optimization.
Thanks for making video on this topic. Is that screenshort even readable. Any high quality link.
Of course! Both, the original and refactored version are linked in the Vue Docs - vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization
No color coding though
Very nice videos! 🎉🎉🎉 But when will you show us something about angular?
(just kidding) keep going!
You can also use VueUse's useFetch composable. But yes, same idea there!
Great video! Many thanks
My pleasure! Glad you enjoyed it 😊
But if you use inline composables, i think we will loose the power of separating logic from the components while doing the component test
What do you think?
Yes and no, because:
1) If you test components, I wouldn't test implementation details but input and outputs.
2) You can always extract business logic without extracting the composables (if necessary)
Wow!! thanks for share
You are welcome ✌
This would be equivalent to mixins for Vue2. You could have inline mixins in Vue 2, also
Kind of, yes. But with better TS support, no naming collisions and a transparent data flow 👌
Btw how to hook up tailwind 3 in the vue playground?
I’d use StackBlitz for that instead 😊
Thank you!
You're welcome!
I believe in dedicating a folder and dump all in it to grow as muc( as you want
Then you are searching for a lot of code often 👀
@ I agree it’s a trade off. But my personal style is to create folder trees with meaningful naming instead of creating a single big fat file. Maybe because I wasn’t able to afford multiple big screens when I was learning to code.
Inline composable => ultra élégant 🎉
Indeed ✔
Am I the only one who gets error like "Block-scoped variable 'useComponentComposable()' used before its declaration.ts-plugin()" ? It's strange that on video there is no error
Do you have an example of code (e.g. a playground link)? Normal functions do not need to be declared before used (hoisting) but arrow functions and variables holding fn's (const abc = function(){}) do.
Great content thank you!
My pleasure! 😋
Coming from react/solid you will get there soon once vapor drops.
Not sure what you mean. Vapor won’t change much API-wise for Vue (ofc perf-wise) and Vues reactivity system is already fine grained 🫠
thank you
You're welcome 😊
Dunno wtf is going on with your screen but something keeps flashing white at the top which makes the video hard to watch...
I know! Mentioned before and sadly only noticed after uploading :(
@@TheAlexLichter :(
More videos about best practices vue and nuxt.
Coming! 👍🏻
It was 2024. Vue developers have finally found encapsulation 😏
Was already found 4 years ago (as shown in the video 😛) but things take time to change the mind
@@TheAlexLichter 😂
@@TheAlexLichter I remember how 20 years ago at the university we were taught OOP and encapsulation, and even then it was something ancient and 101 😏
But I agree:
It's better to reinvent the wheel than to drive without a wheel at all 😅
Well luckily we don’t need OOP in the front end nowadays. IMO it is great in the backend (to some degree) but horrible in the front end.
I’ve also learnt it in Uni 😁
But encapsulation can be done so nicely, and luckily the Composition API doesn’t force us to group by „type“ anymore 🙏🏻
@@TheAlexLichter "Well luckily we don’t need ~~OOP~~ WHEELS in the front end nowadays" - yep, let's just reinvent them 😂😂😂
It might be funny if it wasn't so sad, thb
Have to work with Vue/Nuxt for last months...
And every time I wander how awful it is from the design point of view 😢
The worst thing is that it encourages devs to write bad code - without encapsulation, with duplication and lots of boilerplate
The interesting fact that most of the problems that frontend Vue/React/... devs are fighting so "heroically" now, were obvious from the VERY beginning
While frontenders were desperately fighting against jQuery, mobile devs managed to emerge, grow and even mature: they re-invented Clean-Architecture, design patterns, etc. 😅
But nvm, just a cry from the heart...
Anyway, thanks for the video, and have a good day ?? night 😉
thankss
You are welcome!
"...even in general. If you write a comment to describe stuff, why not write a function, instead of a comment..."
Sorry Alex, but this sounds to me like you haven't seen really large projects with really complex and convoluted logic.
Oh believe me, I’ve seen enough weird code 😁
Also, to avoid misunderstanding: nobody stops you from writing JSdocs/TSDocs for your functions (which I definitely encourage).
But instead of having one 1000 LOC function, writing subfunctions is the obvious way ☺️
I want to follow what the authorities suggest but I'm still unconverted. Nothing I've seen about Composition API including this video makes me prefer it over Options API. I want structure by aspect of component, not by function; for that shouldn't I create a child component? Also, I don't want every line beginning with "const" and looking the same. I notice too that even old-hand Composition API people keep forgetting to append ".value" after every variable, which is a drag and a case where a bit of magic might remain a good thing.
GOD I hate redundant variable prefixes. Both shown and reversed are already terms defining a binary state! lol
Outside of that, what you're basically advocating for here is vue controllers :)
I'd say they add info. See this example:
show method vs. show boolean
reverse method vs. reverse boolean
Not really clear IMO
show method vs. isShown boolean
reverse method vs. isReversed boolean
More clear when reading ;)
@@TheAlexLichter you’ve misunderstood me. You changed the words ;)
shown === isShown
reversed === isReversed
is my point :)
In most cases I find adding prefixes is a symptom of not thinking through the domain language appropriately, usually a sign of lazy thinking. Not saying you are, just been my experience running a software firm and managing lots of engineers :)
To me, suffixes like "String", "List" etc. (think of userList, identityString) are in line with what you mentioned.
The "is"/"has"/"does" prefix is different because it doesn't describe the word but more the action that is triggered by the boolean.
Also isShown, willShow, hasShown, can all have different info, which is another reason why I am in favor of it for booleans
@@TheAlexLichter It's a good argument but one I still fundamentally disagree with. Suffixes as you mention, I agree - they're redundant, and I advise my team not to use them as well.
You don't need the prefix to advertise intent, as that can come from both the method/function signature, as well as its use, eg: if (this.reversed()) reads identical to if (this.hasReversed()). You can't use reversed() in any other context, it's a question about the object's state in the example I provide, and the engineer's intent is already clear.
Regarding your last example, the only one that stands out is willShow, as this is a question about future state, rather than current state, and in that case it probably does make sense for the given context. This is obviously different from canShow, which is a question about potential state, which could also be reworded as "showable()".
Hope that makes sense - and good discussion :)
Tbh, in the end the code still looks awful 😭
Please add at least blank lines before functions so that the code doesn't look like auto-generated sheet that no one is going to read 😖
If you click on the "demo app code" in the description, there are line breaks? 🤔😆
@@TheAlexLichter 😉👍
Not a huge fan of this approach! That will force you to write tons of compostables in a big project. You can easily get lost like that!
Exactly, you will write lots of functions which contain all the related logic at one spot and even give a descriptive name to it.
Which approach would you prefer otherwise? 👀
@@TheAlexLichterI will have to experiment with this. Maybe it is better indeed. The way I am doing it at the moment is exactly what you suggested NOT to do in the beginning, where I group them in a similar way to options api…
@zlatkoiliev8927 definitely give it a try! It will take a bit to get used to but it’ll feel way better to have things grouped by logic, like you’d do in classic JS/TS files too! ☺️
how is nobody talking about the incredible annoying white box glitches through out the whole video? is this another case of js dev just accepting anything as is?
This is literally one of the top comments 👀👀
ua-cam.com/video/iKaDFAxzJyw/v-deo.html&lc=UgwbGl-6UroiU-NO5Td4AaABAg
IMO Composition API structuring sucks
Why? ☺️
@@TheAlexLichter just think Options API is more convenient
Until you “outgrow it” but yeah. Also talked about that recently @ ua-cam.com/video/7sBev_SxWGI/v-deo.html
Nope, sorry, your advice may work for smaller apps of maybe only 200 or 300 files.. but once you get to the couple of hundred thousand files, you will shoot yourself in the foot..
There are advantages to keeping everything grouped by options.. Once you have started to work on bigger projects, you may start to learn this for yourself.
Hey Colin! I’ve worked in projects definitely beyond the 200-300 files mark and there, grouping by logic actually helped understanding what is going on faster than everything grouped by options!
Why you may wonder? Because the code was easier to read and understand than when it would’ve been grouped by options because you don’t have to jump through the whole file 😊
So I think the other way around it is 👌🏻 Grouping by options is the “footgun” for bigger files and projects!
@@TheAlexLichter good luck with that then.. Maybe when your projects get bigger and your teams get more diverse, you will see how it starts to make things worse.. Don't worry, you will get there..
I have no problem agreeing to disagree. Nobody has to take any of the advice I am giving here - and actually it’s good to draw own conclusions.
But I would appreciate not being treated like I am new to the game and “will get there” 😊
@@TheAlexLichter Sorry you feel that way, I am just trying to help you not get stuck in a rut of what you believe now. This will help when you start to work on bigger projects with more diverse teams.. You don't need to take any of the advice. Just trying to help you as you grow.
Then bring on some arguments or leave it 😁So far you said "there are advantages" and listed none. You talk about gigantic project and diverse teams but still listed nothing speaking in favor of grouping by option! Curious for your thoughts (without patronizing plz!)