Design-oriented semi-encapsulated Web Component Development (profile)

The delusion of traditional Web Components

At present, many teams and team have their own set of Web Component system, modular development, encapsulation good, easy to start. It is then hoped that the Web component can be applied to each project that is taken over, saving future development costs. Even consider open source.

This is actually great, but what about a set of Web components that are common to each project? In my opinion, unless there is no pursuit of the project, it is not realistic.

But what about a set of Web components that are common to each project? In my opinion, unless there is no pursuit of the project, it is a delusion.

Why is it that traditional Web components want to eminence unrealistic? Because just like Qin Shihuang eminence, to sacrifice a lot of things.

2. amount of code sacrificed

   If the Web component is to be applied to each project, it must consider various scenarios of each project, so we are bound to expose a lot of API, otherwise we can not cope with it. Take a modal bullet frame example: Some items can be dragged, some did not close the button, and some black masks can be clicked, so, we have at least a new similar, dragable colsable clickable these APIs. Even so, there will be some special needs, such as the frame position up and down ratio 2:3 . The industry's usual practice is two-time encapsulation, yes, the two-time package, is based on the original very heavy Web components, and then churn some code.

4. Sacrificing code Quality

   Some projects do not need to be compatible with older IE browsers, and UI engineers have better and simpler solutions. However, I'm sorry that the Web component is there and only compromises the use of old and smelly traditional compatible implementations.

   Scene support, more code, more logic, the code is easy to chaos, but also more easily out of the bug.

6. sacrificing design and experience

   Web Components need to be abstracted from the UI layer if they are to be used in multiple projects and are packaged well. However, once the UI layer is abstracted, it loses the energy of innovation, and it equals death:

   And the modern web, with CSS3, SVG and other modern web technology is maturing, we can do in the UI presentation layer of the event is very much, update change is also faster. If this innovation is limited by the components, and other competing products in the component UI details of the continuous flash of human, emotional innovation, the interaction is more smooth and comfortable. is bound to be washed up on the beach in the new wave of web development.

8. particle size control of the component

   Because of the project difference, as well as the cooperation of many people and other reasons, the component particle size control is always not just right, properly handled.

10. Cross-sectoral cooperation

    The component is big and heavy, looks easy to start, in fact, the API so much, who remembers to live! We have a real case here, a project with a very high quality, whether it's UI, interaction, and experience, and the evaluation of the parties is good. Then we want to start a new and relatively large project, we want to have a lot of good things from the project to draw on. Design is the same as a group of designers, but the front-end team has changed a person. The ideal state should be this, the new project of the front-end team, directly using the project side of the front-end UI components (in addition to color, size and everything is exactly the same), less variable file color change, minutes seamless transfer, how wonderful AH!

    The final result, however, is that the new front-end team abandons the front-end solution for the previous project, or uses its own succinct pie approach, Seajs + JQuery + ...

However, there is no denying that Web components are valuable for general, especially visual, items that are not highly demanding. There is still a lot of room for improvement when it comes to meeting the requirements of a higher Web project. Here's the question: are we going to discard these Web components for some interactive experience and visual effects?

The answer is obvious, and the Web component is still needed. However, it cannot be used directly as it is now. We need to adapt to the times, change thinking, try to go " design-oriented semi-encapsulated Web Components ."

Second, the transformation of thinking, design-oriented

Traditional Web Components are generally completed by the front-end development, focus more on the function and collaboration. Although there are design support, but still relatively weak. As a result, when a designer makes some micro-innovations, it tends to be constrained by overly assembled components. For example, the designer made some micro-innovation to the dialog frame, such as the following (no title no close large background color block):

To ask the development feasibility, the result, developed a sentence: "Gee, this structure of our current frame component does not support!" "I believe that many of the students have encountered it ~ Finally, basically are designers compromise, or use the traditional frame interaction or layout." Therefore, there are "bitter designers" rumors.

This is extremely unreasonable for an enterprise or team that values experience and design. Incredibly downstream decision upstream, the purpose of technology is itself to design services, the result in turn to limit the design of the play, this is not the cart before the horse!

Therefore, it is necessary for us to change our thinking, design oriented. That is, let designers freely design, we do the technical, service, for specific projects, to adjust our web components, eliminate unnecessary APIs, as far as possible to separate the content of the UI layer, to designers and UI engineers to streamline our components, while ensuring that the components of the UI quality.

Iii. conversion thinking, separation and semi-encapsulation

Design-oriented Web components, which can be said to be tailored to the current design of the Web Components. We all know, custom this thing, although the final effect is good, but the manpower cost is also high! How do you weigh it?

Two points: separation and semi-encapsulation.

1. Separation

Release the traditional component APIs as much as possible and give them to HTML and CSS. At the same time, the UI layer content is stripped from the component, making it easier for the UI engineer to make adjustments, noting that internal adjustments are not the traditional template APIs.

2. Semi-Package

This half package is a parallel comparison of multiple projects, the core function of the non-UI side is still packaged well, the UI layer is variable, so it is called a half package.

The above two points are shown by using the icon:

As a result, our ultimate human cost is almost the same as it used to be (the core modules are the same), the traditional components are two encapsulation, the half package is internal customization, in fact, it is similar work, but the latter code volume and the quality of the UI is much higher:

Here, it is necessary to underline: This "semi-encapsulation" is for different design style projects, for a specific project, its Web components are fully encapsulated, or have a mature API interface .

Four, the use of design-oriented semi-packaged components of the premise

1. important projects, hope to become a boutique project because such projects need to design, and not just to meet the function, let the development of wayward.
2. design and UI engineers want to give force if the designer and develop a level when I did not say; If the UI engineer's HTML/CSS skill and development A level, when I did not say. Because the component will become "half crazy" by the half package.

Comparison of traditional and semi-packaged components

Traditional components like the Chinese law, a set of laws applicable to all provinces, so the law all-inclusive, but, always inevitable omission, for example, male by the man, not that;

Semi-packaged components are like American law, encapsulated in part by the Constitution, passed nationally. The UI layer, which is variable for each project, is like a state-approved law, autonomy and flexibility.

The former is suitable for the main function, code quality requirements of the general project, the latter applies to experience first, toper level projects.

Vi. the practice of designing semi-packaged components

Take the dialog bullet frame of the recent project for example. For a specific project, from the design consistency, the frame of the interactive details are consistent, here is no exception. Includes the following features:

1. Can not be dragged and dragged;
2. Click on the background layer can not be closed;
3. Horizontal center, up and down ratio 2:3;
4. The frame can not scroll the background content, the frame is too high, the frame itself may roll;
5. The frame supports the upper and lower spacing unchanged and the middle adaptive layout;
6. When the frame size changes, the animated support is not directly presented by Duangduangduang.

Everyone should have used the dialog component, if you use the dialog components of your current team, how to meet the above requirements? In my experience, this is the case:

1. Call the generic dialog component, and then create a new JS file in the project, the dialog two encapsulation, applicable to this project;
2. Setting: dradable: false ;
3. Setting: closeable: false ;
4. What's up and down 2:3? There is no such API, don't panic, we kill the components of their own center positioning, and then we reset, or directly to persuade the designer to give up this "meaningless" idea;
5. The global Callback API handles page scrolling;
6. JS real-time calculation?
7. JS Animation, like a very troublesome appearance, the quickest way or directly to persuade designers to give up this "meaningless" idea;

OK, so let's get a feel for what the traditional bullet frame components are doing. First of all, you know, this traditional frame component is very large, the API will be many, such as the famous Kissy light overlay 18 API. Then we also encapsulate the JS code once again on such a large component (traffic Ah, burn money).

If we can meet the design requirements of the package is also very good, the best results seem ... This has been a hassle for development, especially with 2:3 of the first encounter requirements, as well as a highly adaptive pinball frame and animated support.

Damage the code effect is not good, lost the wife also fold soldiers.

Why is there such a tragedy?

The modern Web UI is changeable, and similar UI requirements will certainly be more in the future. Traditional component-oriented features, although seemingly perfect and powerful, the actual UI layer or beyond, the UI layer of a wayward, components will cry.

Here's a look at how design-oriented, decoupled, semi-encapsulated Web Components meet design requirements.

1. The hand is a semi-finished dialog component with some core encapsulation;
2. Any similar can drag and drop, whether there is an element, whether the background click can be closed and so on API related code all kill;
3. UI layer separation, according to design requirements, redesign of HTML, in addition to z-index outside the style control all to the css;html side layer and frame fit, easy to scroll to achieve and highly adaptive frame; up and down 2:3 positioning implementation to the CSS completion, so, when we do animation, Only need to pay attention to the frame inside the change element size, the frame will be automatically positioned (CSS automatic real-time rendering);
4. The scroll bar controls direct component callback processing, and there is no API control because, for this project, there is no need for this design.

Everything except the design scene is discarded, the code is estimated to be less than half (design-oriented), according to the design scene, modify the HTML structure of the Variable UI layer, cooperate with the powerful CSS, give full play to the UI engineer's attainments (separation) in the visual presentation Preserves the encapsulation (encapsulation) of traditional Web components on the frame and callback processing.

The final result: The dialog component's code is tailored, the code is small, the logic is clear and easy to maintain, at the same time, the UI level to design, the frame experience a good, positioning, etc. to CSS, more high-performance. Combined, the quality of the entire component is several floors higher than the traditional component implementation.

Seven, the final small summary

This article is a compact version of "Design-oriented, semi-encapsulated Web Component development," and if you are skeptical about some of the arguments, you can go here and browse through the original. Also, the purpose of this article is to make the Web components of the focus on the construction of "design-oriented", "Half package" is only a balanced design and modular development of a trade-off strategy, the specific project or to package good, small white can also be used.

For me at least, this idea of component development has made the project's component quality, whether it is a UI layer or a code layer, up to a new level.

You may wish to savor, not to give up the traditional Web Component Building model immediately, but can broaden the thinking, transformation ideas, try to design to think, customize the Web Components, away from the traditional and heavy components of the building.