Organize your Composition API code (2k subscriber special)
HTML-код
- Опубликовано: 13 июн 2024
- ✨ The Composition API is amazing - but organizing code is still a challenge sometimes, especially for all the people that were (or are) used to the Options API. In this video I point out common mistakes when organizing code and an easy way to avoid spaghetti code in Vue components with a bit more functionality
Key points:
✔ Building a Demo Application showing issues when organizing code
🎉 A dead-simple pattern to organize CAPI code in Vue Components
🕶 Examples from Evan himself
---
Links:
🔗 Demo App Code play.vuejs.org/#eNq1VVtvmzAU/...
🔗 VueUse useToggle vueuse.org/shared/usetoggle/
🔗 Evan's gist gist.github.com/yyx990803/885...
📺️ Is your function actually a composable • Is your function REALL...
Don't forget to hit that "Subscribe" button, ring the notification bell and give a thumbs up!
🌐 Connect further:
Website: www.lichter.io
Twitter/X: / thealexlichter
Twitch: / thealexlichter
Chapters:
00:00 Intro + Options vs Composition API
01:47 Demo App and Tasks
02:30 Building the feature "with Options API in mind"
05:44 Common mistake: Grouping by options
07:55 Why this is a problem
08:15 Refactoring & Reorganizing
09:26 Are we done?
10:09 Creating a composable for message-related things
13:36 The "secret sauce" - in-line composables
15:55 Learning from the master himself
17:25 Summary 
Наука
The idea of inline composable is very helpful !
Thanks Johnson! Hope you'll use them 😋
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. 🙈
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 💚
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 😊
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 ✌
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 ✔
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 🙏
Very useful, please keep sharing those types of tips 🎉🎉
Thank you, I will! 🙏✨
Wow 🤯 now i know where to start and hiw ro "clean" it
Amazing thank you
Happy to help! 👌
Thanks Alexander. That was really helpful.
Glad it was! 🙌
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! 🙌
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 ☺️
Interesting concept! Thaanks so much Alex
My pleasure!
This is huge! Can't wait to present this approach to my team
Let me know how your team liked it!
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 🔥
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!
Bruv, this was exactly what I was looking for! My setup was getting pretty confusing
Glad to hear you found the video then 🙌
excellent content as always!
Thank you Pedro 🙌 Glad you still enjoy the content ☺
GREAT content again! Thanks a lot
Glad you liked it! 🙌🏻
Very useful video, please upload quality content like this more❤
Will do! Next video coming up today 🙌
Great video and clean real-world problem solvent.
Thanks 👍 Glad it helped!
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)!
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 👌
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 👌
Great video! Many thanks
My pleasure! Glad you enjoyed it 😊
You should continue doing content on youtube, so little quality content related to Vue on RUclips.
Great video!
Thanks! That's the plan! Once a week (except specials and streams) - release every Friday 👌
Glad to hear that@@TheAlexLichter
Very nice Alexander :)
Thank you Guillaume! Hope you'll use the inline composables ✌
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 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
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!
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.
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 content thank you!
My pleasure! 😋
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.
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!
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 👌
Wow!! thanks for share
You are welcome ✌
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 🔥
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?
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
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
thank you
You're welcome 😊
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) ☺️
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!
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)
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"
Inline composable => ultra élégant 🎉
Indeed ✔
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 👌
thankss
You are welcome!
Btw how to hook up tailwind 3 in the vue playground?
I’d use StackBlitz for that instead 😊
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
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)
More videos about best practices vue and nuxt.
Coming! 👍🏻
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 🫠
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 😉
"...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 ☺️
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 👀👀
ruclips.net/video/iKaDFAxzJyw/видео.html&lc=UgwbGl-6UroiU-NO5Td4AaABAg
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!)