Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
From Author:
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.
This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.
FAQ
Tomasz Findly is a full-stack web and mobile developer with 10 years of programming experience. He is a co-owner of Findly WebTech, a mentor and consultant at CodeMentor.io, and the author of 'React, the Road to Enterprise' and 'Viewed the Road to Enterprise' books.
Tomasz Findly discusses two approaches to building components in React: composition and configuration.
The configuration approach involves adding more props to a component to add more functionality. This makes the component easier to use but harder to extend and maintain over time.
Pros: Quick and easy to use, keeps UI and behavior consistent. Cons: Hard to extend or override, more props lead to more conditional logic and complexity.
The composition approach involves using smaller building blocks (components) to compose the functionality of a larger component. This makes the component more flexible and easier to extend.
Pros: Extremely flexible, easy to extend functionality. Cons: Requires more knowledge of building blocks, takes more time and code, easier to diverge from the design system.
You can use the composition approach to build smaller building blocks and then combine them to create a configured component. This way, you get the flexibility of composition and the ease of use of configuration.
Tomasz Findly recommends checking out 'React.io's Road to Enterprise' for learning advanced patterns, best practices, and techniques for crucial concepts like state management, scalable project architecture, performance optimization, managing APIs, and testing.
You can find Tomasz Findly on Twitter, LinkedIn, CodeMentor, and the Road to Enterprise platform.
Tomasz Findly uses an alert component as an example to explain building future-proof components in React.
Video Transcription
1. Building Flexible and Resilient React Components
Today, I will discuss how to build flexible, resilient, and future-proof components in React. We will explore two approaches: composition and configuration. Building future-proof components can be challenging as the complexity grows. Adding features like headers, variants, and icons requires careful consideration of props and styles.
Hey, today I'm going to talk about how to build flexible, resilient, and future-proof components in React. I'm going to cover two different approaches to building components, composition and configuration.
But first, let me tell you a bit about myself. My name is Tomasz Findly and I'm a full-stack web and mobile developer with 10 years of programming experience. I'm a co-owner of Findly WebTech, as well as a mentor and consultant at CodeMentor.io platform. Besides that, I'm the author of React, the Road to Enterprise and Viewed the Road to Enterprise books. I also write articles for Telerik and the Road to Enterprise blogs.
Okay, that's enough about myself. Now, components. So, let's be honest. Building future-proof components is not easy. I mean, well, if you have a component like this, it's very simple. So for this example, I will use an alert component. So for example, if you would want to have an alert component that would display a basic alert message, well, we could do something like this, right? We could receive text entries as props, have some divs with styles, and then render what was passed, right? And here's how we could use it. Just use the alert component and pass the text message inside of it.
So, obviously, that's very simple, but the problem with building good components is that, as we need to add more functionality, the complexity just grows, right? The code is becoming much harder to maintain and extend. So what if we would want to add more features to this alert component? Let's say we just want to add a header as well. So we could receive a header as a prop, and if one was passed, we would display it, right? As shown here in the example. So, for instance, on the right side, we have one alert just with and the other one with both the alert header and the text message.
So what about variants? Well, I guess we could again add another prop, like variant, right? And then based on that prop, and whatever the variant was selected, we could add appropriate styles. So, for instance, we could support variants like success, danger, warning, or info, as you can see on the right side. And that's how we would use it. Just pass header and variant props and some text inside.
So what about adding, maybe, an icon? Well, again, another prop, like icon. If it was passed, and we found a supported icon, then we can render it. Simple, isn't it? And that's how we could use it. So, basically, by default, the icon could be displayed on the left. But what if we want to specify on which side we want it to be displayed? Like, maybe not on the left, but on the right? Well, guess what? Another prop! So, for instance, we could pass a prop like iconPosition, right? By default we could set it to left. And then, if, for instance, it was right, we could specify some classes, right, that would be added on the alert container. Note that I'm using Tailwind here for classes.
2. Using Composition for Flexibility
The configuration approach can become problematic when adding more functionality requires adding more props and conditional logic. It becomes harder to extend or overwrite the component's logic. On the other hand, composition offers a different approach. By using multiple components and passing props, we can achieve flexibility without excessive conditional logic. In the example, the alert component is composed of the alert wrapper, alert content, and alert body components, allowing for more control and easier extension.
And yeah, that's how we would use it, just more props. So, that was the configuration approach, right? Basically, whenever we just need to add more functionality, we add more props. But, well, that can be problematic at some point. Because the thing is, for every new variant and functionality, we need to add more and more props and conditional logic, right?
And sometimes it might just become much harder to overwrite the already defined logic inside of a component or even extend it. So, that's not really the best. The configuration approach makes it much harder. So, sometimes if a component can't be extended, we might need to build a new version of it. Well, as for pros, well, obviously a configuration approach, well, a component built with a configuration approach is quick and easy to use, right? Because you only need to know about what props are really available and what you need to provide. So, yeah. Basically different functionality and visual variants can be controlled via props and that's it. And another benefit of that is that it's much harder to diverge from the design system, right? Because the thing is you only can provide props and that's it. You can't do really anything else with it. So, well, this keeps the UI and behavior consistent.
But, yeah, like I mentioned the problem is that we can't easily extend the configuration build component or override it. So, what can we do? Well, I mean we could obviously provide maybe props like, let's say, a render icon, render header, you know, render body and so on and so on. But again, more props would be just more messy. So, there would be more conditional logic inside of the alert component. So, instead of trying to configure everything, how about we'll use a different approach, composition.
So, in this example, we have three components. First, the alert wrapper, then alert content, and alert body. And to the alert body, we pass the text message. I know three components just for the text message is a bit much, but stay with me. So, how it could look like? Basically, the alert component, obviously, it would receive some props. Then it would render a div with appropriate styles and children, right? So, in this case, the children would be the alert content and alert body. Then we have the alert content. As you see, it's very similar to the alert component. Because, again, it just receives the props. And has a div with some styles. And actually, well, the same will apply to alert body. I know there's a bit of repetition, and we have a few of the components already, but it's worth it at the end.
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
Workshops on related topic
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
- Data store;- Component cross-communication;- Utility functions (DOM, API, etc);And more.
Comments