Component Design Patterns

Rate this content

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.

18 min
12 May, 2023


Sign in or register to post your comment.

AI Generated Video Summary

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.

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.

3. Refactoring and Promotions

Short description:

We combined two components that do different things, making the component more complex. There was a bug in the code due to the complexity. Don't repeat yourself is about knowledge and intent, not just code duplication. We should revert back to the parent component and separate the collapsed and expanded components. I'm working on a new course and also instructing Mastering Next 3 with Vue School. You can find more information on Twitter and my other online platforms.

And then the paragraph tags at the bottom, we're going to conditionally render as well. And then we also have to compute the class, because one is flexbox, the other is grid. In theory, you can make it a single-column grid inside of flexbox, but this is just the first step in our refactoring here. So in the end, by shoving this vfConditional from the parent into the child, our parent component now becomes kind of pointless, and perhaps we could even get rid of it.

But we do have a pretty big problem, in my mind. And so, that leaves us with when not to create this component. And so, we have this short component. But because we've taken two components that do different things, and we've combined them together, we've actually made this component a lot more complex. And in practicing this talk, and writing out my slides, after a bit, I realized that there's actually a bug in this code, which I didn't realize at first, because it is more complex. This V show, this collapse here, I should have removed that negation. And so, at first, it's easy to miss that kind of a thing, because there's lots of things going on here, and to understand this code and what's going on, it's a lot of thinking, a lot of step by step looking through and trying to determine what is going on here. And so, this is ultimately a question of, is it better to keep, is it better to remove duplicated code or not? And lots of people like to follow dry, don't repeat yourself, but actually, don't repeat yourself is more about the knowledge and the intent behind the code and not the actual characters on the screen. And so, although those components look the same, they actually represent very different intents. And so, combining them together, in this case, was actually a mistake. So we want to revert back to what we had before with this parent component here. And then take these article collapsed and article expanded components and, yeah, and separate them out. So we have two simple components instead of one more complex, harder to understand.

So... that is the three patterns that I wanted to cover here. And so now is the end of the talk where I get to shamelessly promote myself for a little bit. And I am working on a new course which should be coming out in a couple months which talks more about these kinds of patterns and goes more into depth about how do we create new components. How do we do that well? And a couple other related concepts. So if you want more information about that, you can follow me on Twitter or anywhere online and I'll be talking about that. I have also... I'm the instructor for Mastering Next 3 which is in partnership with Vue School and if you want to learn Next 3, how to do full-stack development, we cover everything from the basics all the way to authentication and integrating with Stripe and all that kind of stuff with that. And then, of course, there is this book as well if you want to get that online. There's also an e-book version so you don't have to have the physical copy. And there are my links and information. Thank you so much! Please take a seat, take a seat. There were so many good questions but right now, and I love that this one is still, oh this one is still up there with one of the most upvoted questions, and it's one of my personal questions.

4. Michael's T-shirt and Component Structure

Short description:

Michael's t-shirt is awesome. He designed it himself and got it custom printed. Smaller components can improve performance, but the complexity should be considered. Developer experience is important too. When structuring code in large and complex components, using composables can help extract logic. Patterns can be incorporated into component libraries and design systems.

Have you folks noticed Michael's t-shirt, it's pretty awesome. Where did you get it from? Because I might need to order one myself. So I had a few years ago my wife got me a Vue shirt for my birthday but you know, it kind of gets old and worn and so I actually designed this shirt myself and got it like custom printed on. Nice, nice! So now you've got some inspiration you can go and custom print your own Vue t-shirt.

We've got a few other questions in here, I'm just going to jump to the ones that are relevant to your talk. We've got one that says smaller components can often be more performance. They don't load any CSS or JS when it's not needed. But when does the complexity of smaller components outweigh the performance benefits and this is kind of related to when not to create a new component. So it's a bit of a long question, but there's some substance in there, finding that right time to switch over.

Yeah, so I don't have as much experience in performance optimization of web apps, so I can't really speak to that aspect of it as much. But I think in general there is this question of how small is too small? Because eventually you don't want to have 30 files open and each file is five lines, because the context switching between each of those things then is the thing that makes it hard. So maybe performance in a mental capacity way. Yeah, definitely. It's kind of like what Evan was saying as well, there is performance and there is how happy are you as a developer actually writing the code. Yeah, developer experience. I think developer experience is something you want to make sure you optimize for as well.

And another one which is kind of a very view related question, for large and complex components written with the composition API, how do you recommend structuring the code inside the script tag? Yeah. So, one thing that I really like is to, like, we can create these composables to, like, we can create these composables, and so it makes it really easy to actually extract logic out of your component. And so you can do this, like, with reusable composables that you might use in multiple different components, but you can also do, like, a one to one thing where maybe you have one component that just is more complex and you can't, there's no easy way to make it smaller. But you could take, you know, take sections of that script and pull it out into maybe you have three different composables. And those composables are only used in that component. But at least it lets you break out that logic in a way that's organized and easy to understand.

And let's do one more question, because I know we're running out of time. How do these patterns, this one's from Edward, how do these patterns translate to a more abstract component library or design system? If you're already using a component library or design system and you also have these other patterns that you want to bring to the table, how would you bring them in and incorporate them? Yeah. I think they're it's a pretty similar approach, I would say. Working on a component library is there's a lot more thought that goes into the API, like Eduardo was talking about of like making it easier to use. And I think that can in some ways affect how you structure your components. But yeah.

Nice. Nice. Thank you. Now I know you have some extra copies of the book, not just for the questions that were asked. So if you did ask a question, your answer got read. And maybe if you also just want to check out the book, I would say definitely go and meet Michael upstairs after this talk as well. Definitely be able to answer any other questions that we weren't able to get to. But Michael, thank you so much.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!

Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.

Workshops on related topic

Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.
Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.
Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem
IDE of choice (Inellij or VSC) installed
Nodejs + NPM

Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.

Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.
Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
VSCode setup and an empty Vite + Vue project.

Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
- Intro 3D 
- Intro WebGL
- ThreeJS
- Why TresJS
- Installation or Stackblitz setup 
- Core Basics
- Setting up the Canvas
- Scene
- Camera
- Adding an object
- Geometries
- Arguments
- Props
- Slots
- The Loop
- UseRenderLoop composable
- Before and After rendering callbacks
- Basic Animations
- Materials
- Basic Material
- Normal Material
- Toon Material
- Lambert Material
- Standard and Physical Material
- Metalness, roughness 
- Lights
- AmbientLight
- DirectionalLight
- PointLights
- Shadows
- Textures
- Loading textures with useTextures
- Tips and tricks
- Misc
- Orbit Controls
- Loading models with Cientos
- Debugging your scene
- Performance
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.
Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level
NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.

React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.