How to Write Your Own Reusable React Component Library

“MacBOok Pro beside brown mug” by Artem Sapegin on Unsplash

Do you find yourself using some of the same components over and over in multiple projects? This is super common, and with a bit of time spent compiling these into one reusable project, you can save time and boost your efficiency in future projects.

In this post I will create a boilerplate step by step that you can use to start your own component library. I will also develop the requirements and make pull requests along the way, as I mentioned in my last post.

Before we get into coding, my first rule of new projects is always come up with a name and logo. It helps me get engaged in the project and power through that last 10% of work that can take 80% of the time. Also an emoji that’s relevant can help with any branding or marketing you may plan to do in the future. Most of my coworkers think I joke about this stuff. I’m dead serious.

Once, you have your cool name and logo, go ahead and create your repository on GitHub. I’ll call mine rinse-react. It’s like Rinse, React, repeat.

A drop and a cycle icon… pretty on the nose.

Now we can make this thing. The first step is going to be setting up webpack to build our components into a single file that can be imported by other projects. In this example, we will publish to npm at the end.

Setting up Webpack

Webpack can be pretty intimidating. Having worked with it for a few years, I still prefer the simplest possible setup file. That’s what we will go for here! You can check out the requirements listed in the first issue of my repo, so I’ll just address the basic goals:

1. Take in one file, like a src/index.js type file, and output one file, like dist/rinse.js.
2. Handle all the cool file types we will want.
3. Sneak in some new project housekeeping.
4. Don’t forget to npm init because we are starting from scratch!

The changes to our base repo (just license and readme from GitHub’s init) can be found in the first pull request.

Creating Our First Component

One of the nice things about building out these companion style libraries is that we can get down to writing some real code pretty quickly. We want to make sure we can scale this library at any time so I like to take a fairly robust approach to structuring folders from the get-go. You can check up on the requirements of this task in the issue, but here’s my usual approach:

src
·· components
···· Button
······ index.js (export file)
······ Button.js (actual component code)
······ README.md (document each component!)

There will be some other things in there eventually, such as unit tests and possibly some Storybook files (or other visual testing aide). Having a dedicated export file to basically import then export a component may seem a little overkill at first, but once you’ve added many dependencies and are wrapping components in translations and state, it comes in handy. It also helps if you want to introduce TypeScript later, but that is another conversation.

If you would like to peruse the contents of the first component and the explanations of certain aspects, check out the pull request.

How Can We See Our Work?

One of the issues when developing these components is that using them in other projects can get wonky with linking and local development. Fortunately for us, there are a few ways of both documenting and visualizing components so you can work in isolation of the other projects. When you are done and push up your sweet shared component library, you can know what to expect in your app.

There are a few methods, some of the notable methods include MDX and Styleguidist, but for this purpose I think Storybook fits best. To embark on this journey, I opened up an issue as always.

Storybook’s latest v4.0.0 alpha supports Babel 7 and Webpack 4, so we will be using the absolute bleeding edge of the available tech. As time goes on and versions become more stable, the open source project I have started as a boilerplate here will be updated.

To see how Storybook was configured, you can check out the pull request.

Developing and Publishing

At this point we actually have all the tools we need to start making stuff. We have an example component that we can see on a screen. One of the reasons I like this “all the component’s stuff goes in the same folder” business is because of a tool called Generact. This will allow you to rapidly duplicate and intelligently rename components, including their exports and stories. If you had other files, such as styles or unit tests, they would be similarly copied.

Now, how do we use these new components? For this example, I have published my repo to npm. You can view it on its npm/rinse-react page.

You can install this package as a dependency:

$ npm i -S rinse-react

And in your React project, try placing a Button.

// In your component
import { Button } from 'rinse-react';
// In your render function
<Button type="submit" onClick={this.submit}>Hello!</Button>

If you’ve cloned your own copy and renamed it, the first time you publish, you can simply run:

$ npm login
# Enter your username, password and email for npmjs.com
$ npm publish

For future versions, depending on your changes, you can up the version:

$ npm version [major|minor|patch]
$ npm publish

Your library is now in the cloud and available to be used as a dependency in any JavaScript project.

What Next?

There are quite a few places in our newly created library that could stand to be improved. The goal of this post (in Git, anything from tag 1.0.0 and prior) was to get an MVP component library up and running. You could expand your own library, starting with a few things:

• TypeScript
• Jest testing
• CI like Travis or Circle
• Some static documentation with something like docsify

If you think of something cool to add, tweet me! Happy coding!