3 VUE DESIGN PATTERNS You Should Try In Your Code
Vložit
- čas přidán 28. 07. 2024
- 00:00 Container/Presentational
00:41 Higher Order Component
01:10 Provide/Inject
3 Design Patterns to use inside your VUE Applications.
Let me know if you would like to see more patterns!
Repository:
github.com/BackupMiles/VueDes...
Icons used:
www.flaticon.com/free-icons/d... by Freepik
#vue #designpatterns #hoc - Věda a technologie
I’d like to see more Vue design patterns!
I found the process of making this video quite entertaining, with learning new patterns and making the right animation for it. Will definitely make more, thank you 😁
Cool, but some already mentioned... the most useful and used pattern is to actually use state management... especially when you have bigger apps and you are managing a state like user authentications and rights, app config and settings, etc. and of course when you want to prevent component drilling ;) With Pinia is super simple.
I fully agree, stores are a big topic per se and I wanted to keep the video brief, you and the other who mentioned it are definitely right tho
Exactly. Idk why this wasnt mentioned and with Pinia replacing VueX it is easier than ever to manage state
More please! 🙂
Nice way of explaining things. Hope to see more videos!
Keep up the good work :)
Well well well, that's very kind indeed! Thank you a lot :)
we NEED part 2 of this video 👏
Thank you for the kind feedback 😁
Very informative, thanks mate
Nice info! I like HOC pattern, i will implement it. Thanks!
Thank you so much for the feedback! Let me know if you'll have any questions!
Love your content !
keep up the good work
Thank you for the nice feedback! It means a lot to me 😁
I hope to learn more patterns. This video has helped me a lot in understanding why Vue provides those APIs.
I'm glad this video was helpful for you! I'm planning to do more actually, thanks for the feedback 👍
Nice video! Thanks! would like to see more about frontend design patterns, subscribed
I'll try to apply HOC on my Tables rendered in difference pages, currently there're all the same (using v-if, v-else-if, v-else to handle loading & error)
Wondering how would you implement a reusable Form component with Validation for Both Creation & Edition pages (Containers)
Hey, first off, thanks for the feedback! Let me know how HOC worked out for you 😁
Design patterns are pretty cool to talk about, it's always nice to know one more: after my next video, it might be an idea to come back and talk more about the subject
A reusable Form component you say? I think a video of some sort including the topic might be a good idea: on the top of my head, if the component was meant to be reused, the form rules for validation would be passed in as props, as well as the fields to render, but it would surely be interesting to write something well-made. I will definitely expand on this topic!
so you create a whole new component just to do one fetch call? have you thought of the boilerplate/bundle cost for such a pattern?
That would be, as you have correctly pointed out, an unnecessary measure. Container/Presentational is best applied when a component style and logic end up taking a very large amount of code, or to give a better and "foreseeable" structure to your components tree, making the component easier to navigate from a developer viewpoint.
Design patterns, in general, are best useful in projects that can and will reach a certain size, to have a better and clearer organization of your work
@@backupmiles Then the provide / inject pattern is actually an anti-pattern. Instead use a localStorage composable wrapper for things such as theme of your website and use the hook whenever you need it in your components (you don't want clients to switch it every time they load your site, the site should remember it).
Otherwise provide/inject is almost no different from "global" variable magic. There is no typehints for that right now (and I don't think it's very scalable/maintainable). You don't know where your provide begins and where it ends if you forgot that information. When you see an inject you don't exactly know where the object comes from.
When you use a composable, however, you have all that - typehints, import statement that lets you see the source, everything else.
@@theseangle I agree that themes are something that you would preferably want to store permanently, so that the site will be able to remember it: from the provide inject pattern, take away the possibility to provide parent data to some component that is deeply nested.
Composables are super nice and traceable, but depending on the use case you may not necessarily want to pass through it.
Thank you for the interesting insight!
Great video with super effective dynamic animation (one of bests i have seen in videos / tutorials) !
How do you have create purple elements/animations ?
Thank you so much for your kind feedback 😁
Soo I used Adobe Illustrator for all the elements you can see in the video (aka the icons for each pattern), the animations are made with After Effects, and then everything was edited together with Premiere Pro 👍
Hello! Thank you for video. I'm new to Vue, but isn't it a Store concept for such cases like drilling down/up nested entities if we want to pass there something?
Hi! Thank you for your comment, yes a store is indeed made for such use cases! For our use case I wanted to keep it as simple as possibile using VUE's directly available APIs
1:06 wouldn't it be easier if it was just slot that is passed instead of a prop?
Probably yes! I wanted to leave slots out of the scope of this video
question about HOC - why do you need to use component as a prop when u can just simply pass it through slot?
Hi! Thanks for the question: there would be no particular need to pass the component as a prop, as opposed to simply using slots as you have pointed out (and a more VUE-ish way indeed). It was more about the approach of the video: using components as props, to me, appear more readable in a quick-glance scenario, as opposed to using slots
Isn't global state management with Pinia better than the provide/inject pattern?
Absolutely, you are right! Although it is way more organized and functional, I did not want to include the concept of a store in the video, so I went for provide inject as it is ok for a small sized application
If I export my logic from container into outside js files and just call the functions from there, is this considered separation of concerns just like in container/presentational pattern?
Precisely! Whether you separate your logic into an external file or use the container/presentational pattern, you are still keeping your code modular and maintainable, and correctly separating concerns. Nice observation!
@@backupmiles understood, thanks
These patterns are familiar to me but I've never heard of them. Where do you find info like this? I also want know if anyone has ever implemented the mvvm pattern in Vue and what that would look like. Maybe in the next video 😄
I have researched a good deal about these patterns online, Vue has a nice ecosystem (sure, it's no React by any means) so I was able to find some articles about design patterns
Requesting how to test vue component with storybook 👍
Thank you for your comment! Unfortunately I haven't had the opportunity to explore testing components in SB yet, if I will receive many requests like this one I will definitely expand on the topic :)
With the first example I do not agree. Every component has overhead. To put the logic in a container component just to pass it as a prop to another component creates two components each with overhead. To extract the logic imo it's better to or create a mixin (options api) and mix that logic in or use a composable (composition api) to use that logic inside components. But for api calls it's maybe the best way to create a util/href module and write a facade around the api calls and call those methods just within CatRender.
Example two is great. Although I would suggest to use a dedicated variable "Loading: boolean" to indicate if the data is loaded. In that way it's easier to extract the loading logic to a own component and pass the boolean as a prop for reusability (see example 1). Other options to take a look at are v-cloak (options api) or suspense (composition api) or even middlewares on the vue-router..
Example three is a creative way of making the pair reactive. In Vue 3 this can be done with "Ref" and "Reactive". Wrapping the mode variable will make it reactive. Keep in mind that Provide/Inject is heavy as far as I know. Also provide/inject can be very complex and not so understandable for other team members. Maybe an eventbus or global state is better, or even props drilling which is not so bad at all. Thorsten Lünborg wrote a mixin for making provide/inject pairs reactive, which can be found on github. But if Provide/Inject can be avoided, avoid it!
Many people made me notice how provide/inject is not really a good practice, and that even though stores and other solutions would have required a longer video, they would have been better suited. Thank you for your feedback!
@@backupmiles I hope you don't take it personal. It is just to inform others what can be done and why. Your video is straight to the point and those patterns exist. And sometimes you just need them. Thx for the video!
@@Tarabass You make great points, but i dont agree with prop drilling. I believe it causes more confusion in the app and when components are deeply nested, it increases the chance for problems, especially if you are using strict props.
@@obrien8474 I fully agree with you. But in most video's it is presented as an anti-pattern and that it should be avoided. But there are examples where prop drilling isn't bad at all. One example can be an form which receives an dynamic config object from the server, passes each item in the array to a field and that field passes through the icon config. And it's better testable.
Good patterns but you forgot the useComposable
Indeed! The useComposable is a very nice example, as it provides an interpretation of React hooks. Thank you for the suggestion, I will make sure to talk about it in a future video
provide/inject only works for child components. Won't work for passing props from one child to another child with a different parent
Sure, it's no store, the scope is limited to children of the same parent, but it can still be a good trick to pass props without drilling in those cases where a store would be overkill (think small projects)
how you implement client side-effect? do you still apply that on provider component and apply emit on styled component?