preface

In my past experience, in an interview with the quilt cover usually with some questions about the component design, but usually the interviewer and the candidate can only through some actual project experience for the discussion of the design compared to the service side the interview may also involves some design principles and the basic train of thought, but on the front end of the interview process, Design seems to be an experience.

But is design really just an experience?

Obviously not, because experience is a summary of past problems, and there is no standard and no constraint on experience. The projects, teams and businesses experienced by each person form their own unique R&D experience. And the design is in fact in these experiences on the continuous refinement of the processing summary of the r & D standards.

However, front-end component research and development has no standard at all in terms of design at present, which makes front-end component research and development become an empirical skill. Whether it can develop highly extensible, clear structure and easy to use front-end components is not through scientific and reasonable design, but based on the past experience of developers. As a result, experienced maintainers of front-end component libraries are a scarce resource.

With this in mind, I’d like to try to show you some of the things I’ve learned over the past few years from the React component design perspective, which might give you some inspiration.

The body of the

A brief history of front-end component development

There is no way to talk about front-end component design without exploring the history of front-end component development. I won’t write a long story about this, because it’s not the core of this article.

In my experience, front-end components generally go through several phases.

In the early years of portal websites, scripting components based on native JavaScript

I remember eight years ago when I started writing the front end, one of the first components I made was a floating advertising component. If you’ve been around long enough, you’re familiar with the left and right floating ads that were popular on major portals around 2010.

The front-end component is usually a JavaScript script that builds a relatively independent runtime environment through IIFE by anchoring a specific DOM Id.

The front-end components at this point fit into the mainstream development image of JavaScript as a toy language.

2013 was actually the end of this type of component, with the rise of jQuery.

With the rise of jQuery, DOM manipulation is greatly improved, and jQuery’s endogenous plug-in mechanism brings front-end components into the plug-in era.

JQuery brings plug-in components

JQuery plug-in can greatly improve the efficiency of front-end research and development at that time. Although AJAX was relatively popular at that time, the role of front-end was still more attached to visual interaction. Similar to bootstrap, it integrated commonly used jQuery plug-in and extracted the prototype of the first general-purpose front-end component at that time.

Contains the most common rotation charts, navigation menus, Tips, and more.

In those days, it was the gold standard for a front-end engineer to be able to write a rotation diagram by hand

Angular 1.0

Young people who join the industry 15 years from now may have a hard time understanding our obsession with Angular. Angular largely lays the foundation for some of the core elements of front-end development today.

including

  • modular
  • Front-end – based single – page routing
  • ViewModel
  • Data driven

Of course, the most important thing is that Angular brings a different approach to front-end component development than jQuery, by breaking front-end components into different types through a built-in module system

  • Data component
  • Instructions to manipulate the DOM
  • Components with routing

Unfortunately, Angular’s overarching approach ultimately failed to meet the needs of The Times. With the rapid rise of React and Vue, one monopoly has become a three-way rivalry

Virtual DOM and JSX

React’s popularity introduced two important concepts to front-end development, the virtual DOM and JSX, which solved two previous front-end development problems, respectively

  • Manual manipulation of the DOM is inefficient and difficult to maintain
  • Angular introduces fragmentation in front-end component design.

React unified the front-end component design, no matter it is data or interactive. Both are standard React components.

Google-led Webcompoent has been very popular for a while, but from the current situation, it is a bit of a dead end. But I still tend to think that the web of front-end components is the future, whether it’s Webcompoent or not remains to be seen

The above brief history does not contain all kinds of interesting details and branches of history, I just outline the next few relatively important nodes, if you are interested in this history, please leave a comment, I will write a separate detailed article later

React component design problems

Although React unified front-end components into the model given by React through frame-level design, the unified approach could not solve the problem of component types in the actual development process. Moreover, as front-end development became more and more complex, this area repeatedly entered the realm of chaos in my opinion.

Let’s look at the React component design from a different Angle. For example, does the React component have any design?

How do we define components when we develop with React?

I think the answer is very different, because it becomes an experience.

Through the different dimensions, we can see that there is a lot of uncertainty in the existing React component design

  • From a communication perspective, we define a component as a parent component. A component can be either a parent or a child component. So what are the criteria for parent and child components? What do you call it if it’s parallel communication? Sibling components? That deep nesting, is it called ye Sun, grandpa grandpa sun sun sun sun component?

    • In addition, the implementation of component communication also lacks standards, based on event pipeline? Broadcast, unicast, route-based?
    • Is it through context/props? Or hang it on the classComponent’s this?
    • Introduce Redux Mobx or some other state management library?
    • Hook not hook

  • The React framework allows you to define different types of components, such as classComponent, functionComponent, HOC, controlled and uncontrolled components, and custom hook components. When to use useState, when to use useReducer, useContext standards?

  • Defined from a business perspective, user-centric, account components, notifications, and company-specific business components

  • Visually based definitions, tables, forms, navigation, dialog boxes

The uncertainty caused by the lack of design standards made the React component design very difficult. It can be said that because of these uncertainties, the React component, or the front-end component, had no design at all.

Component libraries like AntD mostly define front-end components from the perspective of vision and user experience. However, as I mentioned above, front-end components contain many perspectives, and the expansibility of components will be greatly affected simply by defining components from one perspective. Take AntD’s form component as an example. In practice, it is difficult to scale to fit your own business, so you have only one option: secondary development.

If React and Vue are compared, I think React and Vue are not the same thing from this perspective. React is a UI library that doesn’t care about real development, but focuses on how to implement UI rendering more efficiently. And in this efficient rendering can complete the connection to the external state

React is a management engine for rendering functions. In terms of design, React is always focused on improving the execution efficiency and performance of rendering functions, while ensuring that injection parameters do not affect the efficiency and performance, which is why there is a hook. Because classComponent has significant performance and efficiency bottlenecks

Unlike Vue, which is more like Angular, Vue is a development framework that encompasses all aspects of front-end development, albeit a bit miscellaneous.

So I don’t think the two are equivalent or comparable.

Anyway, let’s get back to the React component design for this article

Let’s try to eliminate the uncertainty in the React component design.

If we discuss the React component design standard based on the above uncertainties, this design standard should be available

  • It can be implemented, it can be translated into some kind of framework
  • Multiple perspectives, not a single perspective to define front-end components
  • Higher abstraction, component abstraction is unified across multiple perspectives.

Given the above uncertainties, we can abstract out some features of the React component

  • Visual sex
  • interactive
  • Data sex

React is state-driven, and its core is State control. So the design around the React component can further extend the features to

  • Characteristics of sex

    • state
    • Operation function

  • Visual states and visual manipulation functions

  • Interactive states and interactive action functions

  • Data state and data manipulation functions

On this basis, we can further define the problems to be dealt with according to different features

  • Visual state

    • Text/numbers directly used for rendering…
    • Style, used for visual enhancement
    • Dynamic effects, in the style based on the addition of the drawing process

  • Visual state manipulation functions that convert input state to visual state, such as transform

  • Interactive state

    • Flags describing interactive actions, such as open, close…
    • Describes state between pages, such as a query on a URL
    • The state caused by a change in the running environment of a component, for example, onLoading in a browser

  • Interactive state manipulation functions, behavior control functions that trigger interactions between users and components, such as controllers

  • Data state

    • Data from external inputs, such as interfaces
    • Locally cached data, localStorage, disks, files

  • Data state manipulation functions, used to communicate with external data control functions, such as calling API services

According to these standards, the rationality of React component design can be judged.

For example,

  • Whether the definition of state does not conform to the standard, common to render the data returned by the server directly on the interface. For components, this leads to visual and data confusion, with knock-on effects when interfaces change. Also bad for component reusability.

  • Mixing interaction with style controls on onClick can lead to performance issues, especially when writing animation effects, as well as code reuse.

In addition to this there are interactivity and data confusion, data manipulation functions that directly manipulate visual and interactive states, and so on.

In fact, in practice, even if has been clear about the standard is also difficult to strictly enforced, and that the development team has a lot to do with the ability of itself, but as the construction industry, construction team, has the high level design firm that the cow force, also have a stand at the gate of contractor, is all a matter of experience of small construction group, a mature industry has its inclusive, But it can’t be all small construction crews.

To implement these standards and integrate design into everyday component development, convention alone is not enough, so I mentioned the possibility of standards being implementable and transformed into frameworks.

Our team is currently trying to develop such a framework, which has been mentioned in several previous articles for those interested.

Git address: github.com/kinop112365…

It’s actually something we’ve been practicing and tweaking. At present, the core goal is to establish an implementable design standard for React component development and provide research and development support.

As for the longer term goal, it should be to promote the web of front-end components.

The latter

A is no industry standard is not mature, a thumb eps industry is inefficient, the front face problems, prompting the front-end natural to component has a strong appeal to the process of research and development of the front-end components research and development, assembly, commissioning, operation process, front-end components should not be merely a few component library so simple, But should be combined with scientific and reasonable design standards, in the daily research and development work can also be well applied. The front end “engineer” is only as good as it gets when it comes to design, although that seems a long way off.

If you have a strong interest in this process and would like to participate in the process and join our team, you can contact me via wechat (SH112365362) or leave a message at 😁