4 Things you should know when writing Reusable Components

Photo by Sigmund on Unsplash

If you were in the frontend space for more than 2 years or working in a startup company, there’s a big chance that you need to write reusable components. It might just be for a small team or even preparing for the next batch of engineers to come. Either way, you will need to know these basic understandings to avoid rewriting the reusable components since you’re not doing it correctly.

Before we dive right into it, here’s the most important reason to use Reusable Components? DRY your code; that’s pretty much it. You can write 10 of the same colored buttons again and again; but why? If you can just do it at once, then why bother writing it over and over again. Maybe that’s an oversimplification, but there are more than just buttons and inputs that can be reused. So pay attention to what those things are that can be crunched into reusable components.

These are the top things that I think will make your life much easier down the road when you’re trying to start writing reusable components.

• Documentation
• Custom Props
• Default values
• Naming Convention

Documentation

No one will know how to use it if there’s no documentation. It might be easy for small components, but things get complicated really fast for more and not common components. You can try full-fledged documentation like Storybook, but sometimes you just need a simple helper that can guide others to use your component. Without the proper understanding of what this component can do, people will just create a new one because they don’t know what this component can do.

Try at least JsDoc; just write a simple 1 liner of what the component can do and write all the params that they can take, and that will benefit your team on how to use the reusable component. There’s a helpful cheat sheet that you can use here. That should be sufficient enough for how to write JsDoc.

Imagine having a simple button component without writing any documentation. When someone else is using your component, they completely don’t know what your button can do and what can be customized.

The only way they understand would be by accessing the implementation of your button. But now, try to compare it to the same component with this documentation.

Which will generate this information upon hovering the instance of this button.

You immediately know that there are only 2 props that we can pass into this button component: title and onClick handler. There are no other common props for a button that you might know from using other components library. But we’ll cover that in the next section.

Custom Props

When developing reusable components, we always need to keep in mind what customizations might benefit the user of this component. Say that there might be cases where we need different sizes of this button. A size prop would be a very good addition to the list of props.

Size usually determines the padding as well as the font size of the text. There should be multiple options that cover different usage of this button.

Check on the size param, there you can easily know what are the possible options. While there’s a better option to show that using interface, having it written in JsDoc is I think a good enough starting point.

Another important thing that people tend to forget is that you can insert the text in between the button tag.

So in the reusable component, it’s pretty common to have that default behavior as well as people might assume it’s already implemented that way. And that is where children prop comes in.

I’m removing all other props since I just want to focus on the children vs title props here. These 2 will basically do the same thing, now it’s just a matter of which prop should trump the other one when both props exist. I think both are valid options, but I personally think children should be a stronger prop than the regular props.

Default Values

Say that you’re too lazy to implement what is stated above and you just want to start implementing the reusable components. This part might be your best friend.

Then at least you will still get this documentation on what those props should be passed with.

Another thing about default values, there are some that you should decide and some might just be better left undefined .

Let’s use the example from above about the size prop from earlier. That one should have a default value to a specific size. Usually medium would be the better option. Leaving the possibility of getting larger or smaller depends on the user’s usage.

But on the other hand, onClick is completely fine to be left undefined. And the reason is that if we have it as undefined then it’s just like passing nothing to the original button component. Nothing would happen and so no default value is needed.

Naming Convention

I realized convention might be a sensitive topic, but I think this one might already be a very common thing from component libraries.

1. The first one is pretty Obvious. React Component should be Capitalized. No other explanation needed.
2. Prop names should be short and easily understandable. Like size is pretty straight-forward, no need to overcomplicate it by using some other synonym of size like measurements or magnitude . And that prop is commonly used in other component libraries as well.
3. Function handler should always start with on like onClick, onChange, onMouseUp, onMouseDown, onDrag, etc. It’s a common thing that React has established for us, and we should keep the same convention when creating reusable components.
   This is important because we usually have another convention where we prepend the word handle and people tend to pass that handler to the reusable component.

So please avoid that kind of prop name as part of the common naming convention that many people have agreed upon.

Conclusion

There are tons of other things that could help you write better reusable components, but these should help you to get started. I’m also still learning how to make it better, so I would really appreciate any kind of constructive inputs for me to become better!