DEV Community

Writing clean, reusable components in React (best practices)

Programming with Shahan on February 29, 2024

🔑 Key Concepts What are reusable React components? You can think of them as building blocks. They are independent pieces of code that c...

Read full post

Sean Dinan • Feb 29

Very good write-up! One thing I would add in terms of reusability is render props. For example, if you have a generic button that renders a logo and a label, you can maximize reusability with a renderIcon prop.

const IconButton = ({ label, renderIcon, onClick }) => (
  <button onClick={onClick}>
    <span style={{ marginRight: '1.5rem' }}>
      {renderIcon(styles.buttonIcon)}
    </span>
    {label}
  </button>
)

/* ...other component code */
<IconButton label="Save" renderIcon={(style) => <CheckIcon style={style}/>}/>

Programming with Shahan • Feb 29

Thanks for sharing. I tried my best to keep this article as simple as possible focusing purely on beginners.

There are more advanced concepts for reusable components in React. Most of the time, we use Hooks in React for building reusable comp. Actually,they were introduced as a way to write reusable and stateful logic in functional components without needing class components.

But I believe, beginners should understand the React fundamental concepts pretty clearly first before jumping into advanced topics. That is what the article is about.

Abhay Joshi • Mar 3

Thanks for writing this great article. As you mentioned this is focused for beginners, may be, title also can include that information.

Fatemeh Paghar • Feb 29

The discussion on why incorporating API calls directly into button components is a bad practice is insightful. The step-by-step solution presented, extracting side effects and passing them as props, showcases a thoughtful approach to handling complex scenarios, ensuring that components remain truly reusable.

The examples provided, especially those related to buttons and navigation bars, effectively illustrate how to design components for maximum reusability. The emphasis on passing each functionality as props allows for flexibility and adaptability, crucial in diverse web development scenarios.

Overall, a well-crafted and informative article! 👏

Programming with Shahan • Feb 29

I appreciate your detailed feedback

Edwin • Mar 1 • Edited

Nice article! I would like to add:

It can be difficult to define what the responsibilities of the component are. You will need to be very strict about the API of the component (meaning what props it accepts).
The process of building reusable components needs to be clear for all team members. I've seen it happen that someone needs a change to a component and adds very specific business logic to an otherwise reusable component. This decreases reusability of the component.
- The better solution is to simply create a new "specialized" component that builds on top of the reusable component, this is the strength of React and trivial to do.
- Duplicating the component code is also an option, but not really preferred since you will have to make changes in multiple places, which can become hard to maintain.
I found that developing components with Storybook helps a lot, because (1) you work on the component in isolation from the app, which forces you to think about the component API more and (2) you are creating "living documentation" (changes to the code are immediately visible) that is easy to find for all team members.
There is a fine line between a good reusable component and something that is over-engineered and too complex to use. You can only decide yourself (based on your use case) how much you need to be able to customize your component through props. Again, often it is better to create a new component instead of adding a new feature.
- Do you need to support custom styling through className or do you need completely headless components? Should dark mode be built in?
What I've learned is that if you have two options for an implementation, you should pick the one that allows you to easily make changes in the future.
- If you are building a button that has a "danger" state, you could add an <Button isDanger={true}> prop, but it might be better to do <Button type="danger"> if you foresee multiple types being added in the future (also, having the props <Button isDanger isWarning /> does not make sense).
However, you should also realize that we cannot predict the future. Adding a feature "because we might need it next sprint" is a bad idea, because requirements change all the time and it leads to over-engineering.

Like I said, building reusable component is not an easy task and it takes some practise, but leads to better code quality down the line.

Programming with Shahan • Mar 1

Great explanation. Its really helpful.

Rense Bakker • Mar 1

Yes! Great article on writing good reusable low level components. I just want to point out that you may not want to apply these same rules to all components in a project when they are higher in the tree because of excessive prop drilling (passing down props down the entire component tree). In terms of layering I think it should be something like this: app/root -> composable layout -> (... additional app structure, all composable) -> business logic (actions/fetch/side effects) -> reusable leafs.

Programming with Shahan • Mar 1

I agree.

Khaled Md Saifullah • Mar 1

Nice demonstration. Thanks for sharing this.

Programming with Shahan • Mar 1

Thanks for your feedback.

Sakeena Navavi • Mar 1

great article!

Behan kumar • Mar 2

Great article! , i hope this article will help to all beginners including me.

Lotfi Jebali • Mar 3

thanks for sharing

Alexander Opalic • Mar 2

good article the same applies to otoher frameworks like vue, angular.

Programming with Shahan • Mar 2

yes.

Uttam Sharma • Mar 1 • Edited

Well explained thanks for sharing

Programming with Shahan • Mar 1

Glad it helped.

TonyMartin • Mar 3 • Edited

Scenario: You have a reusable component say "ButtonSave" which take props be label or styles or even icon.
A situation where this button is used in 100 different pages, and now your boss tells you a change(add/remove/etc) on the button.
You have to apply those changes in 100 location.

What would be the best practices on that ?
// maybe create dedicated wrappers for each usecase?

Jose • Mar 5

Ótimo artigo :)