There are a lot of articles about component library design, but most of them are from the UI perspective or visual specification level, but with the development and iteration of front-end technology, the front-end job is no longer as simple as the implementation style defined in the past. This article will talk about component library design from the point of view of a technical student.

Component library application scenario thinking

Components actually lies in the nature of code reuse and abstraction, this aim was to improve the development efficiency, can say is the soul of a component of the business scenario of deconstruction, such as the various controls of abstraction, events of abstraction, the style of abstract, etc., and through the combination and configuration of the way of business needs, to some extent a component library is like a kit, How to design the components that are provided for the development of a business scenario requires a deep understanding and thinking about the application scenario.

For example, c-side component library needs more thinking on UI, performance and browser compatibility to pursue more extreme interactive experience and visual experience. Meanwhile, THE UI of C-side application often changes according to the theme of festivals and activities. In the design of component library, personalized expansion space should also be taken into account.

The b-side component library pays more attention to ease of use and reusability to ensure the high-speed iteration and efficient use of middle-stage or B-side tool applications. At the same time, the B-side application will involve a lot of data display, and add, delete, modify and check operations, which requires the component library to have a finer division of responsibilities and richer choices in interactive controls.

In addition to the different business scenarios of the application, there may also be a diversity of platform scenarios, such as whether the same set of component libraries can be reused in H5 and applets. These all need to be taken into account by the component library designer at the beginning of planning.

Current mainstream component library analysis

One is based on the ecology of several major front-end frameworks, which have formed their own styles and specifications in design, and also have their own precipitation, such as Element based on Vue ecology, antD based on React, etc. Their advantage is that they are mature enough to cover almost all business scenarios, but their disadvantage is that component libraries are costly to migrate across frameworks.

Another category is component libraries that are designed to meet cross-end requirements. Usually, the bottom layer relies on a set of cross-platform development frameworks, such as Taro of JINGdong, mpVue of Meituan, Rax of Taobao, etc. Their core idea is write One Run Anywhere. In terms of implementation, such component libraries mainly use the foundation provided by frameworks to smooth out the differences of various platforms as much as possible. Enables users to implement services on multiple platforms based on a set of development specifications. The advantage of this type of component is that it can reduce the learning cost of developers on cross-platform, but the disadvantage is that the component library is not rich enough and the scenarios that can be covered are limited

In addition to the above two categories, Tencent’s OMI is a cross-end and cross-frame implemented by using the characteristics of Web COMp, which can be regarded as an attempt of the next generation front-end framework.

Component library planning

In fact, the design process of component library is similar to the design process of a product. There will be preliminary scene research, competitive product analysis, requirements sorting, user experience (here should be called development experience), and continuous trial and error iteration.

Based on the above considerations and analysis, I will try to plan the component library as follows:

Component requirements:

  • Component glue layer –> Interface between component and actual business

  • Component proxy layer –> Enables flexible invocation and local refreshes within components based on proxies

  • Component interaction layer –> Abstracts functions based on interaction events according to business scenarios and is injected through decorators

  • Component extension layer -> Implement component cloning, inheritance, extension

  • Component library CLI –> facilitates component iteration and engineering

  • Performance –> Achieve minimally granular re-rendering

Component libraries address pain points

  • Function Component does not extend easily externally
  • Implement local updates when components and callers interact to improve performance
  • Reduce the cost of frame migration by connecting the front frame with the glue layer
  • Encapsulating event-driven state management can also be extended with a state component

Component internal system:

  • style

  • The event

  • state

  • inheritance

Component library architecture selection (tentative, may be adjusted later)

Based on RAX, combined with the development of mono REPo, peer DEP and component polymorphic protocol, the introduction on demand is realized to ensure the interface unification of the business invocation layer in the cross-end scenario and maximize the characteristics of each end.

(Tentative, subject to change later)

  • Local refresh and cross-level invocation
     Modal.proxy.visible = true;
     Modal.show(config)
Copy the code

  • Extension inheritance

    / / clone
const Modal2 = Modal.clone();
Copy the code
    / / extension
const Modal2 = genModal({
    methods: {
      cancel() {
        console.log('%c rewrite the cancel'.'color:#299865'.this);
        this.visible = false; }}});Copy the code
    // Batch scaling
import {factoryAuto} from 'component'
const {Button, Modal} = factoryAuto(pubConfig);
Copy the code
    / / inheritance
const Button2 = genButton(Button1.proxy, newFeature)
Copy the code

  • Lightweight state components


    <Button 
         x-for={(item, key) in statusList} 
         type="+success" 
         onClick={_ => trySingle(item)} >
        wait{key}
     </Button>

Copy the code

    function trySingle (item) { performance.watch() item.choosed = ! item.choosedif (item.choosed) {
          return new Status('pending... ', { backgroundColor: 'green'})}else {
          return new Status(null)}}Copy the code
  • Decorator injection
   @addTransition('visible')  
   class BaseMix extends Base {}
Copy the code
  • Scope scope component (local render)

<Button scope={item}  
    x-for={(item, key) in scopeList} 
    type="+success" 
    onClick={_ => {tryScope(item)}} >
    wait{key}
</Button>

Copy the code

function tryScope(item) { performance.watch(); item.choosed = ! item.choosed; }Copy the code
  • Event decorators (loading, lock, etc.)
    @addLoading
    class EventCtxMix extends EventCtxBase {}
Copy the code
     function Okfunc() {
        return new Promise((resolve, reject) = > {
            // Encapsulates anti-relock and loading effects
            setTimeout((a)= > {
              resolve()
            }, 1600)})}Copy the code

The future of component libraries

One of the characteristics of front-end technology is that it changes quickly. In addition to the component capabilities provided by various frameworks, the concept of Web Components has become a hot topic in recent years. In addition, function components came along with the emergence of React hooks. Compared with class Compontents, function Components based on hooks are more flexible in design but less extensible externally. Based on this consideration, I have a common sense idea that encapsulates the interface of the logical layer and style layer of components on the upper layer of the framework, and completes the rendering of view layer only with the help of components through glue layer and component connection, thus breaking the dimensional wall of component library and framework, and the core part of component library can be migrated to other frameworks and even Web Componens. Just re-coding the glue layer. Of course, this idea still needs a lot of practical basis from the final landing.

link

Webpack build process and comb
A preliminary study on UI automation test framework Cypress
Practice of Canvas in front-end development