每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；微博：https://weibo.com/openingsource；電報群 https://t.me/OpeningSourceOrg

今日推薦開源項目：《復古遊戲 Pyxel》傳送門：GitHub鏈接

推薦理由：這是個 Python 的遊戲引擎，目的是做出復古風格的遊戲。它不僅在畫面上很復古——完全的像素風格，而且在功能上也很復古，比如只能使用16種顏色和同時播放4種聲音。如果你對復古的遊戲感興趣，興許這個項目會很對你的胃口。

今日推薦英文原文：《How to Write Your Own Reusable React Component Library》作者：Connor Wilson

原文鏈接：https://itnext.io/how-to-write-your-own-reusable-react-component-library-a57dc7c9a210

推薦理由：在做自己的項目的時候你很容易發現自己會重複利用以前試用過的東西——組件或是其他什麼，把這些容易重複的組件編寫成一個庫是一個不錯的選擇

How to Write Your Own Reusable React Component Library

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:

Take in one file, like a src/index.js type file, and output one file, like dist/rinse.js.
Handle all the cool file types we will want.
Sneak in some new project housekeeping.
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!

2018年9月14日：開源日報第190期