Organize your Composition API code (2k subscriber special)

แชร์
ฝัง
  • เผยแพร่เมื่อ 25 ส.ค. 2024

ความคิดเห็น • 182

  • @johnsondev169
    @johnsondev169 7 หลายเดือนก่อน +32

    The idea of inline composable is very helpful !

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thanks Johnson! Hope you'll use them 😋

  • @antonioparodyguzman3548
    @antonioparodyguzman3548 6 หลายเดือนก่อน +7

    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!

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      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 😊

  • @vineethedappal
    @vineethedappal 8 วันที่ผ่านมา +1

    I always had this confusion on how to organise code while using composition API. Thanks a lot for this, very helpful video.

    • @TheAlexLichter
      @TheAlexLichter  8 วันที่ผ่านมา

      You are very welcome 🙏🏻

  • @ChrisVisserDev
    @ChrisVisserDev 7 หลายเดือนก่อน +15

    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!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +3

      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 💚

  • @Discoh4rry
    @Discoh4rry 7 หลายเดือนก่อน +35

    Nice video! But the blinking in the top while screen recording is pretty annoying... maybe you can fix that for future videos.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +10

      Yes, sorry for that. Was the first and last time that happens, misconfigured recording settings. 🙈

  • @muratozalp3763
    @muratozalp3763 6 หลายเดือนก่อน +1

    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

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      You are welcome! 🙌

  • @joshdeltener2012
    @joshdeltener2012 7 หลายเดือนก่อน +3

    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!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      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 👌

  • @howard5526
    @howard5526 8 วันที่ผ่านมา

    This video introducing the composable function gave me a new idea on how to organize my code. thx

    • @TheAlexLichter
      @TheAlexLichter  8 วันที่ผ่านมา

      Glad I could help! 🙌🏻

  • @zanfras1149
    @zanfras1149 7 หลายเดือนก่อน +4

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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)!

  • @JohnKomarnicki
    @JohnKomarnicki 7 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      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 ✔

  • @Tarabass
    @Tarabass 7 หลายเดือนก่อน +1

    Great video again, Alexander. Thx for the heads up on structure the code this way.
    And congrats with your channel! You're growing fast 🎉

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thank you Peter! Happy that you enjoyed it 🙏
      Trying my best to put out the best content I can + being consistent ✌

  • @EHBRod13
    @EHBRod13 4 หลายเดือนก่อน +1

    Bruv, this was exactly what I was looking for! My setup was getting pretty confusing

    • @TheAlexLichter
      @TheAlexLichter  4 หลายเดือนก่อน

      Glad to hear you found the video then 🙌

  • @valacshiro378
    @valacshiro378 2 หลายเดือนก่อน +1

    Wow 🤯 now i know where to start and hiw ro "clean" it
    Amazing thank you

  • @jnl88
    @jnl88 6 หลายเดือนก่อน +1

    Your videos are super helpful for me migrating a project from Nuxt 2 to Nuxt 3. Thanks for the tips

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      Glad I could help! If you have any other questions or topics you are curious about, let me know ☺️

  • @marco.arruda
    @marco.arruda 6 หลายเดือนก่อน

    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!!

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน +1

      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 🙏

  • @rayan_azzam
    @rayan_azzam 7 หลายเดือนก่อน +1

    Very useful, please keep sharing those types of tips 🎉🎉

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thank you, I will! 🙏✨

  • @torerik1778
    @torerik1778 3 หลายเดือนก่อน

    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.

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      Yess, glad you like it! 🙏🏻
      Hope the refactor will go well 🔥

  • @ivanfrances8913
    @ivanfrances8913 6 หลายเดือนก่อน

    This is huge! Can't wait to present this approach to my team

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      Let me know how your team liked it!

  • @hangor3620
    @hangor3620 7 หลายเดือนก่อน +2

    You should continue doing content on youtube, so little quality content related to Vue on TH-cam.
    Great video!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +2

      Thanks! That's the plan! Once a week (except specials and streams) - release every Friday 👌

    • @hangor3620
      @hangor3620 7 หลายเดือนก่อน

      Glad to hear that@@TheAlexLichter

  • @Rostikchi
    @Rostikchi 7 หลายเดือนก่อน +1

    Thanks a lot, Alexander! The content is instantly applicable.
    Have only one comment, that blinking rectangles in the upper part are a bit distracting.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thank you for the feedback! It sadly was a recording accident noticed too late. Was the first and last time that happens 👌🏻

  • @mohamedhiggy5242
    @mohamedhiggy5242 6 หลายเดือนก่อน +1

    Interesting concept! Thaanks so much Alex

  • @Kingside88
    @Kingside88 7 หลายเดือนก่อน +1

    Great video and clean real-world problem solvent.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thanks 👍 Glad it helped!

  • @CryptographicLoL
    @CryptographicLoL 7 หลายเดือนก่อน +1

    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!!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      Thanks a lot 🙏
      Great suggestion! I've wrote it up the list 👌

  • @alimaher1
    @alimaher1 7 หลายเดือนก่อน +1

    Thanks Alexander. That was really helpful.

  • @codewithguillaume
    @codewithguillaume 7 หลายเดือนก่อน +1

    Very nice Alexander :)

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thank you Guillaume! Hope you'll use the inline composables ✌

  • @arnaudkinnoudo3351
    @arnaudkinnoudo3351 3 หลายเดือนก่อน +1

    GREAT content again! Thanks a lot

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      Glad you liked it! 🙌🏻

  • @pedrohde
    @pedrohde 7 หลายเดือนก่อน +1

    excellent content as always!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thank you Pedro 🙌 Glad you still enjoy the content ☺

  • @elhamzeinodini4828
    @elhamzeinodini4828 4 หลายเดือนก่อน

    Very useful video, please upload quality content like this more❤

    • @TheAlexLichter
      @TheAlexLichter  4 หลายเดือนก่อน

      Will do! Next video coming up today 🙌

  • @TheAlexLichter
    @TheAlexLichter  7 หลายเดือนก่อน +4

    Did you ever wrote a "// props" comment (or similar)? 🧐

    • @NathanChase
      @NathanChase 7 หลายเดือนก่อน

      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!

    • @Tarabass
      @Tarabass 7 หลายเดือนก่อน

      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 👍🏻

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      @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 👌

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      @Tarabass Discipline helps a lot there! Thanks for sharing it in the future! Let me know if there are any remarks 👍

  • @atnguyentien3208
    @atnguyentien3208 7 หลายเดือนก่อน

    Very helpful video, bro. Thank you so much! This knowledge is what I found so long ago.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      You are welcome! Not a "new pattern" per se, right. But lots of people don't know about it!

  • @LearnVue
    @LearnVue 7 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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 👌

  • @ronaldjuarez8991
    @ronaldjuarez8991 7 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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.

  • @mahdirashidi5104
    @mahdirashidi5104 6 หลายเดือนก่อน

    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

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      My pleasure! Yeah, inline composables really help structuring the code 🔥

  • @ItsRyanStudios
    @ItsRyanStudios 2 หลายเดือนก่อน

    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 👍

    • @TheAlexLichter
      @TheAlexLichter  2 หลายเดือนก่อน

      Thanks 🙏🏻
      Let me know how your time likes it!

  • @fffarzan
    @fffarzan 7 หลายเดือนก่อน +1

    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!🤘

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Hey! Great the you use Nuxt 3 now! Enjoy it 😊
      And happy that my video could help you organizing the code better!

  • @A28480
    @A28480 7 หลายเดือนก่อน +1

    Great video! Many thanks

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      My pleasure! Glad you enjoyed it 😊

  • @carminator12
    @carminator12 7 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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 👌

    • @hangor3620
      @hangor3620 7 หลายเดือนก่อน +1

      Imagine you have a large file with 1k+ lines of code you inherited from other dev... Not so convenient anymore

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      @hangor3620 Exactly, that's the time where grouping by logic will shine!

  • @wedocreations
    @wedocreations 3 หลายเดือนก่อน +1

    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

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน +1

      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?

  • @muhamadnasir6236
    @muhamadnasir6236 7 หลายเดือนก่อน +1

    Wow!! thanks for share

  • @unitedstriker95
    @unitedstriker95 2 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  2 หลายเดือนก่อน +2

      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) ☺️

  • @JulioCampoSwork
    @JulioCampoSwork 6 หลายเดือนก่อน

    Nice video dude, composable are very usefull even more in same file, i only use it when the component is short

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน +1

      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.

  • @adrianpdm
    @adrianpdm 4 หลายเดือนก่อน

    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.

    • @TheAlexLichter
      @TheAlexLichter  4 หลายเดือนก่อน

      Thank you 🙏🏻
      Great idea! I helped with the v2 lifecycle page actually so could be a nice case

  • @sphex813
    @sphex813 7 หลายเดือนก่อน +1

    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?

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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 🙈

  • @macrooooo__
    @macrooooo__ 6 หลายเดือนก่อน +1

    what’s the shortcut for renaming all similar words simultaneously?

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      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)

  • @DeepStreamBits
    @DeepStreamBits 7 หลายเดือนก่อน +1

    This would be equivalent to mixins for Vue2. You could have inline mixins in Vue 2, also

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +2

      Kind of, yes. But with better TS support, no naming collisions and a transparent data flow 👌

  • @phip1611
    @phip1611 7 หลายเดือนก่อน

    Very nice videos! 🎉🎉🎉 But when will you show us something about angular?
    (just kidding) keep going!

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      You can also use VueUse's useFetch composable. But yes, same idea there!

  • @nyambe
    @nyambe 7 หลายเดือนก่อน +1

    Can you organize by name also? For mesageOriginalText etc. the thing ia tomorrow you might not remember what isReverased reverses.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      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

  • @ivan.jeremic
    @ivan.jeremic 7 หลายเดือนก่อน

    Coming from react/solid you will get there soon once vapor drops.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      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 🫠

  • @chambaderaphael8946
    @chambaderaphael8946 7 หลายเดือนก่อน +1

    Inline composable => ultra élégant 🎉

  • @doktordaxter
    @doktordaxter 7 หลายเดือนก่อน +1

    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 :)

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      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"

  • @ricko13
    @ricko13 7 หลายเดือนก่อน +2

    is just me or parts of the video are glitching?

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +1

      Sadly not just you. A little mistake with the recording settings - won't happen again!
      Luckily no code is hidden or obstructed

  • @LuckyStilet1
    @LuckyStilet1 8 ชั่วโมงที่ผ่านมา

    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?

    • @TheAlexLichter
      @TheAlexLichter  16 นาทีที่ผ่านมา

      “Above” the composables that use it together, but still as close as possible (so they are co-located)

  • @ramon7910
    @ramon7910 หลายเดือนก่อน

    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?

    • @TheAlexLichter
      @TheAlexLichter  หลายเดือนก่อน +1

      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 👌🏻

  • @shuanwang4227
    @shuanwang4227 7 หลายเดือนก่อน +1

    thank you

  • @gunnarkieck2063
    @gunnarkieck2063 7 หลายเดือนก่อน

    Great content thank you!

  • @s4ndeep1203
    @s4ndeep1203 7 หลายเดือนก่อน +1

    thankss

  • @rayan_azzam
    @rayan_azzam 4 หลายเดือนก่อน

    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?

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      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)

  • @alwaisy
    @alwaisy 6 หลายเดือนก่อน

    Thanks for making video on this topic. Is that screenshort even readable. Any high quality link.

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน

      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

  • @n0xQuZe
    @n0xQuZe 7 หลายเดือนก่อน

    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?

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      Thanks a lot! Also a great suggestion for a topic, added it to the list 👌

  • @aazubakin
    @aazubakin 5 หลายเดือนก่อน

    More videos about best practices vue and nuxt.

  • @user-fy7vk4df4t
    @user-fy7vk4df4t หลายเดือนก่อน

    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

    • @TheAlexLichter
      @TheAlexLichter  หลายเดือนก่อน

      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.

  • @nyambe
    @nyambe 7 หลายเดือนก่อน

    Btw how to hook up tailwind 3 in the vue playground?

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน

      I’d use StackBlitz for that instead 😊

  • @apglazkov
    @apglazkov 3 หลายเดือนก่อน

    It was 2024. Vue developers have finally found encapsulation 😏

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      Was already found 4 years ago (as shown in the video 😛) but things take time to change the mind

    • @apglazkov
      @apglazkov 3 หลายเดือนก่อน

      @@TheAlexLichter 😂

    • @apglazkov
      @apglazkov 3 หลายเดือนก่อน +1

      @@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 😅

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      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 🙏🏻

    • @apglazkov
      @apglazkov 2 หลายเดือนก่อน

      @@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 😉

  • @AndrzejBMF
    @AndrzejBMF 6 หลายเดือนก่อน

    "...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.

    • @TheAlexLichter
      @TheAlexLichter  6 หลายเดือนก่อน +1

      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 ☺️

  • @adamskhan
    @adamskhan หลายเดือนก่อน

    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.

  • @apglazkov
    @apglazkov 3 หลายเดือนก่อน

    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 😖

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน +1

      If you click on the "demo app code" in the description, there are line breaks? 🤔😆

    • @apglazkov
      @apglazkov 3 หลายเดือนก่อน

      @@TheAlexLichter 😉👍

  • @zlatkoiliev8927
    @zlatkoiliev8927 3 หลายเดือนก่อน

    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!

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน +2

      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? 👀

    • @zlatkoiliev8927
      @zlatkoiliev8927 3 หลายเดือนก่อน

      @@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…

    • @TheAlexLichter
      @TheAlexLichter  3 หลายเดือนก่อน

      @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! ☺️

  • @CompanionCube
    @CompanionCube 5 หลายเดือนก่อน

    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?

    • @TheAlexLichter
      @TheAlexLichter  5 หลายเดือนก่อน

      This is literally one of the top comments 👀👀
      th-cam.com/video/iKaDFAxzJyw/w-d-xo.html&lc=UgwbGl-6UroiU-NO5Td4AaABAg

  • @user-wy3mn3jf8q
    @user-wy3mn3jf8q 2 หลายเดือนก่อน

    IMO Composition API structuring sucks

    • @TheAlexLichter
      @TheAlexLichter  2 หลายเดือนก่อน +1

      Why? ☺️

    • @user-wy3mn3jf8q
      @user-wy3mn3jf8q 2 หลายเดือนก่อน

      @@TheAlexLichter just think Options API is more convenient

    • @TheAlexLichter
      @TheAlexLichter  2 หลายเดือนก่อน

      Until you “outgrow it” but yeah. Also talked about that recently @ th-cam.com/video/7sBev_SxWGI/w-d-xo.html

  • @ColinRichardson
    @ColinRichardson 7 หลายเดือนก่อน +1

    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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +4

      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!

    • @ColinRichardson
      @ColinRichardson 7 หลายเดือนก่อน

      @@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..

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +4

      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” 😊

    • @ColinRichardson
      @ColinRichardson 7 หลายเดือนก่อน

      @@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.

    • @TheAlexLichter
      @TheAlexLichter  7 หลายเดือนก่อน +5

      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!)