Component Design Patterns

Rate this content
Bookmark

How do you write a good component? In this talk we’ll explore several different patterns for writing better components. We’ll look at techniques for simplifying our components, making them easier to understand, and getting more out of the components we’ve already got.

This talk has been presented at Vue.js London 2023, check out the latest edition of this JavaScript Conference.

FAQ

The main topic of the talk is about clean components, focusing on patterns and methods for writing cleaner components and simplifying code.

You should create new components when your current components are too big or complicated. This approach helps in simplifying the codebase and making it easier to use.

VIPs (Very Important Patterns) are patterns that help in extracting the code in the body of each branch of a conditional without needing to know much more about the code. This is possible because each branch is semantically related and distinct.

Self-documenting code is code that clearly explains its purpose and functionality as you read it, without needing to deeply analyze the conditions and logic.

You should not create new components if combining them makes the component more complex and harder to understand, even if it reduces duplicated code.

The DRY (Don't Repeat Yourself) principle is about reducing redundancy in code. However, it's more about the knowledge and intent behind the code rather than the actual characters. Combining components that look the same but serve different purposes can be a mistake.

A composable in Vue.js is a function that helps to extract and organize logic from a component, making it easier to manage and understand.

For complex components written with the composition API, it's recommended to use composables to extract and organize logic into reusable or one-to-one functions, improving the component's structure and readability.

The patterns for clean components apply similarly to a component library or design system. However, more thought needs to go into the API to make it easier to use, which may affect how components are structured.

You can learn more about these patterns and clean components by following the speaker on Twitter, enrolling in the 'Mastering Next 3' course in partnership with Vue School, or reading their book available online.

Michael Thiessen
Michael Thiessen
18 min
12 May, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The Talk covers clean components and when to create new components, as well as patterns for writing cleaner components and the benefits of VIP patterns. Refactoring and separating code into separate components can make it shorter and easier to read, reducing complexity. The importance of not repeating oneself and the benefits of using smaller components for performance and developer experience are discussed. Composables can help extract logic in large and complex components, and patterns can be incorporated into component libraries and design systems.
Available in Español: Patrones de Diseño de Componentes

1. Introduction to Clean Components and VIP Patterns

Short description:

I will talk about clean components and when to create new components. We'll cover patterns for writing cleaner components and when not to create new components. We'll also explore VIP patterns and their benefits.

Thank you for that intro. That was great. It's actually really awesome to be here today because exactly one year ago, I quit my job and went into doing this whole teaching view and writing articles and creating courses and books and stuff full time. So, thank you for having me.

So, I would like to talk to you about clean components. And in talking with different people in the community and seeing what questions are asked on Twitter and things that I get in my email inbox, I have seen two fundamental questions come up again and again. The first is that we want to know when do we create new components? Do we create smaller components? Do we create bigger components? And like, is this component too big or too complicated? Should we pull it out into something else? And so this is like something that we deal with every single day. But once we've figured that out, we also need to figure out how we do this well. And it's not just about moving pieces of code around in your file system and like doing all sorts of things like that. But we actually want to simplify our code base and make our code easier to use.

So in this talk, we will cover three main things. Patterns and methods for how to write cleaner components and to simplify our code. And we'll just scratch the surface of these two questions because they're pretty huge questions. But hopefully, you'll come away from this with a couple things that you can apply. So we're going to cover some patterns there. And at the end, we're also going to cover when not to create new components. So the first set of patterns is around VIPs. And they're really nice because we can basically look at the different branches. And most of the time, we can extract the code that's in the body of each branch without needing to know much more about the code that's going on there. And we know that we can do this because of two things. The first one is that each branch of this conditional is semantically related. So the code that goes into each different branch works together for the same purpose. You might know this as cohesion. But really, we're just talking about code that works together. And the second reason is similar. Related to that. And it's that only does each branch work together, but each different branch is distinct. Otherwise, we wouldn't have a conditional. We just, you know, have your code run. So to see this in more detail, we're gonna take a look at an example.

2. Explaining Component Code and Refactoring

Short description:

It's a component that shows a list of articles on my blog. It has an expanded view and a collapsed version. By refactoring and separating the code into separate components, it becomes shorter and easier to read. We can also push the logic into the child component, reducing complexity in the parent component. The result is an article display component with combined code and a conditional based on the collapse prop.

And this example is oh, I forgot to connect to the Wi-Fi here, so we will not be looking at this example. So I'll just give you a quick explanation. It's a component that shows a list of articles on my blog. So either you have an expanded view that shows, like, the date and the description, or you can have the collapsed version that shows at the end of the blog post all, like, the different related articles. So this is the code for that component. And I don't expect you to read through this whole thing right now. I will have my slides available later on, so just so you know.

Yeah, so you can see that at the top level we have a VF there with the two different bodies of this branch here. And they do different things. One is a collapsed version. One is an expanded version. But they although they are similar, they do although they are different, they are sharing some code in there. So, they look similar. But we can refactor that pulling out into separate components. And not only is this code shorter, but it's much easier to read at a glance. We can easily see article collapsed and article expanded and know that's the intention of what this code does. And this is what self-documenting code is like. It tells us what it does as we read it without us having to, you know, think deeply about what's the different conditions and all the different things that are going on.

And one quick pattern that I wanted to throw in here but don't have time to go into depth is that we can take all of this V4 logic here and we can actually push it into the child component. And the reasoning behind this is similar to preferring methods like filter and map and reduce over just writing out your for loop every single time. So what do we do when the branches are, even though they're distinct, they are quite similar? Well, something that we can do with this VF here is that we can take that VF and actually push it down into the child component. So we're taking the complexity from this parent component and putting it into the child component. So in our instance here, we have this parent component here with our collapsed and expanded components. And respectively, they look something like this. So we've got a Nuxt link in each one. And the expanded one also has some paragraph tags there. And if we combine it, we might get something like this article display component, where we have taken the code that's similar and shoved it together and made it into one component that's a little bit longer, but not too bad. And of course, we have to take that conditional and now move it down into the child. So we have a few different things going on here. We've got this v show, where we have to switch based on this collapse prop.