This article is wang Yidan original article, first in the front-end learning guide.

Recently, the company jumped on the componentalization bandwagon of shared UI, creating a new Repo to house shared UI components, such as drop-down menus. I started writing my React form component two weeks ago out of frustration with the historical version of the React form component. After a few setbacks, I learned a lot about it. I will write an article about how I wrote the React form component. Then the company group shared a video of this presentation: Best Practices on Building a UI Component Library for Your Company (David Wells) – FSF 2016, I had a lot of feelings after reading it. This article is a summary and discussion of the lecture content.

Getting back to the topic, if you work on a large team, or if your enterprise has many departments, how can you implement global UI components that span the boundaries of the various sections? Imagine a scenario where your entire company uses the same UI code for common components, your accounting tool uses it, your blogging tool uses it, your live chat tool uses it, and you can see it on mobile, desktop, or Web. How convenient would it be? You don’t have to implement similar forms, buttons, or lists over and over again. This is a relatively ideal setup because you only need to maintain one code base no matter where you are, and all global resources are in one place so developers can easily find the code they need and contribute to it. At the same time, sharing UI components provides a consistent experience for your user, who sees and feels the same regardless of which tool he is browsing or using, mobile or desktop. Note the concept of synchronization. For companies with many products, sharing the UI means that a UI upgrade affects the entire company. That’s a good thing in most senses, but it can sometimes cause a lot of trouble, as we’ll talk about later. Your components should also be complete and not conflict with any third-party packages used by your team. To sum up, how to design the UI architecture of your team’s products so that it has both the above advantages and good scalability and performance is the focus of our discussion today.

In this paper, React is mainly used as an example of UI componentization. As the core philosophy of React is the componentization of page segmentation, we can easily introduce the concepts in this paper into it.

Let’s first look at a typical example of UI Design guidelines, which is Salesforce’s UI library Lightning Design System. It provides very detailed UI rules and how pages and components of each product should be handled, which is worth learning and referring to. Here’s what a style guide should look like:

  1. The documentation is written by your team members. If you use React, you can generate the documentation by commenting Proptypes directly and using React-DocGen.
  2. Code preview You should provide a place for developers to debug code in real time so that users of other components can better understand the props.
  3. Example provides some example code on how to import their data into the UI, so that other developers can get started with their usage more quickly.
  4. Compatibility, such as specifications on how to use additional content such as warnings, loading messages, to provide a consistent user experience.

So how do you build a component library? To answer this question we can break it down into the following small steps:

  1. Break down the whole problem into small pieces.
  2. How do I deal with CSS?
  3. How to socialize resources such as variables, ICONS, etc?
  4. How to package it for easy use?
  5. Start making money from it!

First, let’s take the problem apart. We should think of everything displayed on the page as a component. This means that the first thing you do when you get a draft from a designer is translate everything you can see on the page into a zillion pieces. This is also the React philosophy: reuse components.

Next, we combine the small parts into larger components. Atomic Design proposed by Brad Frost has to be mentioned here. The idea is similar to the one in this article, that atoms form molecules, and molecules form tissues, which form templates and then pages. If you look at these examples, the tag, the input, and the button are each “atoms,” which together form a “molecule.”

Second, CSS has always been a thorny problem. How should we handle class name conflicts? How to use third-party library CSS files? How do I ensure that it does not conflict with CSS files? How to ensure mutual independence? There are a number of solutions to these problems.

The PostCSS + CSS Modules solution that David Wells mentioned in his talk and that our company is currently using. Modular CSS with React Is a good example of Modular CSS with React. Specifically, see this use case:

/* Thumbnail.jsx */
import styles from './Thumbnail.css';
render() {
  return (<img className={styles.image}/>)
}
Copy the code
/* Thumbnail.css */
.image {
  border-radius: 3px;
}
Copy the code

The resulting HTML tag and CSS would look something like this:

/* Rendered DOM */
<img class="Thumbnail__image___1DA66"/>
Copy the code
/* Processed Thumbnail.css */
.Thumbnail__image___1DA66 {
  border-radius: 3px;
}
Copy the code

Here we’ll import CSS modules from our thumbnail. JSX file, and get the hash CSS class name from the style variable introduced.

Another tool mentioned here, PostCSS, fixes CSS 4 compatibility issues by prefixing all your CSS files to suit different browsers.

So do you really need to use PostCSS and CSS Modules? You can ask yourself questions like: Do you work on a team? Do you use CSS files from third-party libraries? Does your product run in a third party environment? Do you want your product to experience consistently in any environment? If your answer is yes, you may choose to try this solution, because it basically resolves the problem of class name conflicts and browser compatibility.

Third, how to deal with shared resources. For global variables and mixins, we recommend several PostCSS plug-ins instead of using a preprocessor language like SASS. This can be explained by a simple Postcss config:

var vars   = require('postcss-simple-vars');
var mixins   = require('postcss-mixins');

var postCSSConfig = [
  mixins({ mixins: require('./mixins') }),
  vars({ variables: require('./variables')}),]Copy the code

Here we extract global mixins from a mixins.js file and global variables from a varibles. Js file, which will take effect in all CSS files you compile with PostCSS. In practice it is very similar to less and sass, as shown in the following example:

.hyo { @mixin MarsPower; /* Define */ color in mixin.js:$MarsRed; /* Define variables. Js file */}Copy the code

For ICONS, we generally choose SVG because of its lightweight and convenience. The basic workflow is for the designer to make SVG, introduce SVG in your JS code, optimize SVG with ‘webpack-svgstore-plugin’ and generate Sprite, injecting Sprite into the DOM. Here we can use the SVG use tag in the form:

< SVG > < use id = "icon - aaa" > < / SVG >Copy the code

The fourth and final step, how should we build and pack?

First, there are a number of tools available to make developing the React component more enjoyable. Here are a few common third-party libraries: Carte-blanche is an awesome React development tool that allows you to test your React components in a browser in a few simple steps. It also allows you to randomly generate prop to test if your components will crash due to prop exceptions. React-storybook is a very similar choice for Carte-Blanche and is the tool I used to develop Hyo. React – DocGen document generation tool. You can import a React folder directly and it will automatically generate documents for you if you add comments in the PropType.

Be careful to use semantic versions when updating versions. Whenever you start writing a new build, you can do a bit of research on Github. Standing on the shoulders of giants is a great way to get things done.

Finally, DW recommends the following file structure for packaging:

I couldn’t agree more. Packaging each small component entry separately, flattening your file structure so that components can be used with each other, is very helpful for development efficiency and scalability.

Sometimes it’s hard to see which components you’re using on which pages. Here you can use a monitor component to query the components you use. This is handy when you want to update a Component and you want to know which pages or components depend onit to change. DW provides an implementation that allows you to implement your Monitor Component according to your needs.

Finally, we summarize some common problems with React component development. (At least I have encountered –) First of all, before making the design, I should understand the features to be implemented, discuss with the designer and write down my own requirements, and whether there are any available substitutes on the market. Try not to define too many prop, otherwise it will be very hard to maintain later. Second, give users as much customization as possible, such as how content is rendered and sorted, preferably by opening up an API so that users can define their own, because you can never predict and satisfy all users. Third, test on all browsers, which is a cliche but sometimes forgotten. Finally, define and follow Lint’s rules from the start, using AirBnB’s configuration as a starting point.

I hope everyone can get something out of writing this AD nauseam. Finally, Hyo is my first serious open source project. I hope you can have more stars! Here | | Demo here | document

Add micro signal: Xiedaimala03, code: write code

A daily question, weekly resource recommendation, wonderful blog recommendation, work, written test, interview experience exchange answers, free live class, group friends share light… Countless benefits are given away for free