Many companies have their own component libraries, but their use is not satisfactory. Here are some of my own views and opinions

thinking

Think long and hard before planning a tool that the whole team will use

First, the following points should be made clear before developing a component library:

  • At present the status quo
    • What are the problems if you don’t build your own? Why not use ANTD/Element
    • Who raised what questions
    • Analyze why these problems occur
    • Which problems must be solved and which are advanced in stages
  • Desired goals
    • What is the positioning of a component library
    • What scenario is the component library built for
    • What are the phase objectives
    • What is the desired end result
  • The specific implementation
    • Which problems are solved by which methods
    • What are the considerations for subsequent iterations

At present the status quo

It’s funny to encapsulate a component, or even a component library, just because front-end development doesn’t have to write it repeatedly for part of the code or style, and it often ends up with the following problems:

  • The code is scattered but highly coupled, with many unclear responsibilities
  • Encapsulation is too rigid and the responsibilities of exposed attributes are unclear
  • Low maintainability and inability to respond to changing requirements
  • Low reliability, no error processing for upstream data, no compatibility processing for downstream users

In the end, iteration was impossible, because even the original developers could not change the code due to the quality and version problems, and the related users complained, and then it was reconstructed again, the same design idea, but changed the writing method based on the known business scenarios, and then became a new historical burden after a period of time…

When you fork someone else’s library so you can easily change it and export it, don’t you think people will say the same thing about the library “you wrote”?

You will find that if you only seek solutions from the perspective of a salesman, you will not be able to get the recognition of other salesmen

Component libraries exist to improve team productivity, not just for individuals to write less code. The former is the goal, but the latter is just one way to achieve it.

Desired goals

A qualified component library should make users feel two things:

  • Constraints (why do they have to be passed this way?)
  • Convenient (as long as this can be passed yeah ~)

Substandard component libraries tend to focus on the latter, but the former is more important

On the premise that party A’s requirements can be realized, the establishment of constraints will allow the team to form an inherent solution to a problem, and this process will contribute to the generation of inertia

At the same time, this inertia, once established, results in two things:

  • Bridging the differences between people
  • Improved communication efficiency (not only development, but also design, product, testing, etc., of related people on a working link)

We should know that in the process of teamwork, the least efficient link is always communication. A good team is not a whole team, but what to do as a whole, everyone’s pace tends to be consistent, so that the efficiency is high

The specific implementation

There are a lot of things to consider when writing a public library, and the following three main points illustrate them

Logical division

  • Avoid one-off, non-generic, and unnecessary encapsulation
  • Cross-level or cross-reference is not allowed, and a clear relationship between superiors and subordinates should be formed
  • The detached logic code should be as “independent” as possible to avoid becoming “inseparable from each other.”

Encapsulation of logic

For a management platform framework, the goal is less code for development, less documentation for products, and no need to repeat output every time there is a new business

For development, there are two specific points:

  • In most cases, you can copy the demo to achieve all kinds of interactive effects
  • In a small number of cases, components can provide additional possibilities to meet specific needs

In the encapsulation process, only key attributes are exposed, multiple possibilities are provided, and commonly used values are taken as “default values” and clearly defined, which can meet “most requirements only need to be referenced without thinking, while a small part of special requirements can also be met”.

Maintenance and development

As an upstream UI library, consider the downstream users

  • After the upgrade, it ensures that most downstream situations do not need to be changed
  • Components should be added, removed, or modified for good reason (requirements or bugs) and in accordance with the principle of minimum impact
  • Components should be designed to allow for future changes

future

A UI framework alone will not solve the problem, and there are three stages of thinking about the future:

  1. UI library, precipitation stable and efficient components
  2. Snippet generator that collects business case code
  3. Page generator, output valid templates

This is more of a solution for mid – to back-end projects

conclusion

Component libraries output constraints, which improve team communication by smoothing out individual differences, and unified solutions, which improve team work by creating inertia