preface

As a front-end UI component library, it should meet two requirements from a style perspective: consistency and customizability [1].

Both of these points are fairly straightforward. Consistency ensures that the component library is visually consistent, rather than patchwork, and at a higher level there may be specifications to follow. Customization requires component libraries to expose interfaces that developers can configure to form their own style of component libraries.

consistency

But what are the specific aspects of consistency? For designers, it’s clear, but for us front-end developers, what exactly does it mean? How do we translate this into code? See the design specification section for details.

Can be customized

According to the granularity of customization, it can be divided into component-level customization and theme customization of the whole component library. Those of you who have experience with components know that with specific components you can pass in certain parameters or theme parameters and the components can behave differently. In addition, some well-known component libraries provide methods for theme customization, such as ANTD-Mobile, Vant, and Element, in particular, provide a variety of methods for theme customization.

Design specification first

The consistency mentioned above is guaranteed by “design specifications,” which can be a lot of things. In our eyes, it may be a set of seemingly disorderly universal variables in the component library (design specifications ≠ universal variables), but in fact there are some routines in it. It is also suggested to communicate with the designer more, and generate collision of thinking. You will find some different thinking in the process of writing code. During my communication with designers, THIS experience was very profound.

What does the design specification include?

What are the design specifications that are closely related to component libraries? A few days ago, Lin Xi, front-end architect of Ele. me, mentioned the following in the sharing of “Vue Component Library Construction Practice” :

  • Unified Visual Style
    • color
    • layout
    • The font
    • icon
  • Unified interaction effect
    • Time, slow
    • Mobile path
    • Deformation, arrangement

How does the design specification land?

In fact, there is a key word: unity. How do we ensure uniformity? Yes, it is the general variable mentioned just now (but I still do not agree with “design specification = general variable”, it is hard to express this feeling). Take ANTD-Mobile as an example, it contains the following contents [2] :

  • Colors (Font, Fill, Global, border, Transparency)
  • The font size
  • Font family
  • Rounded corners
  • The frame size
  • Spacing (horizontal, vertical)
  • highly
  • The icon size
  • Partial component style

In fact, once we understand the design specification, we can also understand the general variables in the component library and feel that there is some internal system between the variables, and when writing the style of the specific component, we will be more or more able to follow this specification, rather than random definition.

Related information:

  • Design variable scale and naming standard
  • default.less

Theme customization

Theme customization is a core style-related feature that most component libraries provide. However, there are many specific solutions, but there are only two solutions:

  1. With the help of gulp/ Webpack and other plug-ins related to packaging tools, configure the style variables that need to be customized, and overwrite the value of the strain during packaging.
  2. Manually modify the common variables, or write a new set of style files to override the component library styles.

For details, refer to well-known component libraries:

  • Ant Design Mobile
  • Vant
  • Element

However, for the enterprise internal component library, this is not a strong requirement, on the contrary, for a set of component library to provide multiple sets of color requirements a little higher. There is a difference between color matching and theme customization, because color matching requires that different skin styles exist at the same time, and theme customization is equivalent to just one set of colors.

If multiple color schemes are used, adding a set of color scheme files can also achieve the “theme customization” function.

Other Common Styles

In addition to the relevant styles in the design specification, there are also, but not limited to, the following common/reusable styles:

  • reset / normalize
  • hairline
  • animation
  • util / mixins
  • clearfix
  • …

This is not only a component library, but also a common style in general projects. I believe you all understand this, so I won’t expand on it here. But it’s also important and part of the foundation of the component library style!

The code structure

The following is a reference to the well-known component library after the design of a style code structure, for reference, for brick.

Style ├ ─ ─ the core | ├ ─ ─ animation. The SCSS | ├ ─ ─ color - card. SCSS | ├ ─ ─ hairline. SCSS | ├ ─ ─ mixins. SCSS | └ ─ ─ the normalize the SCSS ├ ─ ─ Themes | ├ ─ ─ skin | | ├ ─ ─ _brown. SCSS | | ├ ─ ─ _green. SCSS | | ├ ─ ─ _pink. SCSS | | ├ ─ ─... . | | └ ─ ─ _white SCSS | └ ─ ─ the default. The SCSS ├ ─ ─ the core. The SCSS └ ─ ─ index. The SCSSCopy the code

In addition, component-related style variables are placed in the component code directory for ease of development, although this is rarely the case for later maintenance (adding “color matching” requires updating each component-style specific code). Generic component libraries, however, write them in generic variables to facilitate topic customization granularity down to the component level.

Looking forward to

Some style related issues to consider:

  1. Icon
  2. Hd solution
  3. Compatibility (flex compatibility, etc.)
  4. According to the need to load
  5. …

In addition, in fact, component library has general component library and business component library, general well-known component library belong to the former, many solutions are not necessarily suitable for the internal business component library, so in the design also need to fully consider the business needs, find the most suitable for their own/optimal solution.

reference

  • General discussion of component library styles · Issue #14 · IUAP-Design/Tinper-Bee
  • Ant Design Mobile of React – Ant Design
  • Vant – A lightweight, reliable library of Vue components on mobile
  • Element – Web site rapid prototyping tool