ISUX: Design-oriented semi-packaged Web component development

preface

This article is a baptism of knowledge for the brain. When we think of components, we usually think of reuse, which can be used by various projects. The component in this article is a component for one specific project, but a half-wrapped half-child component for others. Design – oriented, project – oriented Web component development is the theme of this article.

I. People and components

At this stage, the Web components we use are all written by people, so individuals play a crucial role in bringing them to life. A person’s skill background, personal preferences, and even worldview can be reflected in the components. However, no one is perfect, so to create a perfect component, it needs many excellent colleagues from upstream and downstream to integrate their best world into it and cooperate to complete it. Among them, the following four positions have high participation:

Notice that the front-end developer is downstream of the Web component development process; It’s nothing, everybody works together, the components get done, the project gets done, the product gets done, everybody’s happy. In practice, however, since there is no front-end major in the university, those responsible for the development of web components in the team are mostly transferred from back-end development, which has little to do with components, or have obvious brand of back-end development. In other words, front-end development is not only downstream, but also a third of its body outside of web components.

The birth of a Web component is ideally a collaborative effort between design, UI engineers, and front-end development. There is a saying how to say, the ideal is full, reality is very skinny.

The reality is that most Web components are implemented by one or more front-end developers, following industry conventions, ahead of UI design and away from UI refactoring. What does that mean? For example, a pop-up layer component has a title, a close button, a main content area, and a OK/close button at the bottom. This structure is a convention in the industry. When developers write these components, they will use their intelligence to encapsulate and design the API well. The purpose is not to care what the designer will design the pop-up layer looks like, because I reserved the class name interface, the UI engineer can change the skin. At the same time, the whole station reuse of components can be guaranteed. Mature, well-packaged, API-rich Web components already exist before the project begins.

Dear friends, read now, you do not think there is no problem, very good ah! ? Yeah, everyone thought Nokia was great until the iPhone came along.

From the human point of view, the biggest problem with this seemingly awesome approach is that it ignores the division of labor. There are limitations in the so-called specialized skills, and there are priorities to hear, and there are also limitations in development, or it is difficult to avoid things in human nature.

1. Position and role

As you all know, designers and programmers live in two different worlds, so there are a lot of obstacles when one role takes on the work of the other, and one of the most important is design focus.

Front-end developer write web components, actually also is a kind of design of the code, at this point, the programmer temperament of the front-end developer design nature is focus on the component functions, generality, extensibility, and ease of use, after all it’s a piece of, he is good at for the UI, will set aside the API or other interface, also can meet the demand of the conventional design.

If the interaction designer or UI designer is writing web components, the UI and customizable interactions are the focus of their design, and if it develops well, it can become another school directly competing with the function-oriented Web component school (at the front end of the development background). However, the current situation in China is that designers generally do not participate in direct code construction.

In fact, by job category, UI development should be the role most suited to building Web components, balancing the beauty of design, the beauty of refactoring, and the beauty of code. Unfortunately, due to the low threshold, the level of good and bad are uneven, especially JS’s control ability is limited, so the final result is that the construction of components fall on the development of strong engineering atmosphere.

Can see, although unreasonable, but the feeling must already. Someone may want to call: “long li bothersome, dog skin plaster besmear to now, in the end where unreasonable, you to say!”

OK, just calm down. As components can only be developed and realized, the front-end development has a very big say in the design and use of components, while the downstream determines the upstream. Designers and CSSer are just a decoration in the eyes of components. Let’s say the designer made some minor innovations to the Dialog box, such as the following (no title, no closing large background color block) :

Asked if it was possible, and the developer said, “Oops, this feature is not currently supported by our popbox component!” I’m sure many of you have encountered this kind of situation. In the end, it’s basically a compromise of designers.Use traditional popbox interaction or layout. That is why there are rumors of “helpless and miserable designers.”

Helpless painful designer so helpless painful to work for many years, fortunately, we so come over. However, things are constantly evolving, technology is constantly improving, as CSS3, SVG and other modern Web technologies become more mature, we can do a lot of events in the UI presentation layer, update and change more quickly. In this context, it is clearly irresponsible for the product to let development decide the design. Other competitive products constantly show humanized and emotional innovations in component UI details, and the interaction is more smooth and comfortable. And you’re stuck with the idea that “we’re a mature frame component, we can’t change it”, and you’re doomed to be washed to the beach by the modern Web wave by using “Duang duang duang duang” stiff, mechanical, mechanical frame components.

For page engineer, Cut figure zai, in fact, also quite helpless pain. For those who have no position in the department, we have learned a new layout that has 2 less nested tags than the traditional implementation, and meets the needs of various scenarios. Great!As a result, the developer said, “Our TAB component doesn’t support your structure, you need to adjust it.”

The specific components of a specific project should be collaborative, but the “I wrote the components, I’m the spokesperson” mentality limits creativity in design and refactoring. That’s what doesn’t make sense.

2. Play to your strengths and avoid your weaknesses

What does a component do? It’s “lazy”, start a new page, “pop”; Start a new project, also “pop”. Function bang bang, the task is completed, the wife need not worry about me to work overtime to return late any more!

Steal what lazy? Mostly stealing laziness from people who aren’t good at it. It’s human nature. The designer doesn’t know the code, and he wants components that are straightforward to visualize; The page creator, the component he wants is the JS part that he doesn’t have to worry about; Front-end developers, on the other hand, want to ignore the HTML layout of components.

Well, components are now written at the front end of the development background, so much of the HTML layout and style presentation is integrated into the Web component, and some of the dynamic presentation is controlled by a plethora of apis. So, development use, as long as according to a specific routine, you do not need to write pages and so on, the component is great!

There are many examples of this, such as the TAB component in the well-known open source project Kissy. According to my observation, the tabs are either created dynamically through JS scripts, and any special requirements are implemented through rich API interfaces or callbacks. In short, components only need to play with JS, not HTML; Or you can apply a fixed HTML structure and a className value. This is more in line with the JS profound front-end development of lazy mode.

Wait, for reasons of length, I won’t give you an example.

There is nothing right or wrong about this. Some enterprises are function king, business oriented; Some enterprises are product king, experience first. Different corporate cultures, different product requirements, different team sizes and technical capabilities determine the presentation and usage of Web components. Web components are great as long as they meet the production and growth needs of the enterprise. Therefore, whether a collection of modules like Kissy is suitable for small and medium-sized enterprises and start-up teams that focus on user experience needs to be carefully considered by executives. Maybe jQuery UI would be a better fit.

At least for me, I would never use a Web component that imposes too many restrictions on HTML (such as how nodes must be…). :

KISSY 1.4 srcNode must require the content node to contain the class name ks-overlay-content…

“Foster strengths and circumvent weaknesses” was originally a commendatory term, obviously, I put it here, is to say its bad. There is a saying well said, called the art has specialized. Front-end development will HTML/CSS, after all, compared to program development, the threshold is very low, in the related field also immersed in some years, when building Web components, feel HTML/CSS applications are relatively smooth, functions can also run. However, in the HTML/CSS area of deep expertise in development, front-end development of web components such as HTML structure design dare not flatter. Here’s a real example:

To implement an Autocomplete component that is positioned relative to the text box (no JS repositioning is required for resize compared to absolute positioning), front-end development is implemented by wrapping a layer around the text box

Tag, Settings
positionfor
relativeAnd then the Autocomplete main list container is in this package

Inside, definitely positioned in the

, left/top values are associated with the size of the text box.

The final implementation, the effect is some, compatibility is also possible, in the front end development should be OK, self-satisfaction. But it’s pretty bad in my opinion!

The one that’s wrapped around the outside

Tags are completely redundant, we do not need to include tags to achieve the relative text box positioning we want, and compatible with IE6+. The current implementation of this package

This may look like an auxiliary, but it actually leaves behind a super bug that instantly reduces component vitality (suitability) by 50%.

For example, if the parent > input selector becomes a grandparent, the text box style will become invalid. With the addition of “relative”, the z-index hierarchy of elements is further complicated and the maintenance cost increases.

The big catch is that it’s not uncommon for Autocomplete components to have drop-down boxes that exceed the container’s height. However, since you have a position: Relative parent outside, as long as any container outside has overflow:hidden, Your Autocomplete pull-down is cut in the middle, partially invisible; If overflow:auto/scroll, the annoying scroll bar will appear. This component is basically dead! However, without the annoying position: Relative parent on the outside, Overflow: Hidden would not dry out the drop-down list, and the Autocomplete component would remain immortal, increasing its applicability by a whole order of magnitude.

There is a *-placeholder element, not to mention that the label element has no for attribute. It is important to remember that approximately 80% of the browsers of enterprise products support native placeholder(including color customization). For this part of the browser, I can’t really think of any reason to customize placeholder effects. Most likely, front-end developers don’t know that any browser that supports placeholder properties can be customized with CSS. That is, the technical depth and vision limitations of front-end development itself.

We summarize the above ramble, just want to express that the limitations of people bring the limitations of Web components, only by cooperating with each other, say goodbye to single job, can make a breakthrough in Web components. But is that realistic at this stage? There is such a lack of outstanding front-end, especially those that can undertake upstream and downstream. If we want to seek a breakthrough, can we start from other places?

Component abstraction and encapsulation

When we write web components, we always try to abstract the functionality and encapsulate the API as much as possible. Thus, when we use these components, we only need to set up some common apis to meet our daily functions.

I’ve been doing this for a long time, and almost every open source Web component in the industry, including web components within teams, is designed this way.

However, as time went by and I immersed myself in various types of projects, I found that trying to encapsulate components through JS as much as possible was not the future trend, but might become a constraint.

1. Development of modern Web technology

Modern Web technologies such as CSS3/HTML5 continue to evolve, and the obsolescence of IE6. The browser itself can do much, much more than it used to. For an extreme example (both real examples existing in the factory) of a web component that simulates a single check box, the API (the default events callback API) might look something like this if you followed the traditional component development model:

From a code point of view, it’s beautiful, right? It is also functional, and all kinds of needs can be met; The ABSTRACTION and encapsulation of the API is no disadvantage. But, pardon my foolishness, what’s the value of 600+ lines of JS code? In IE9+ browser, single check box custom effect is not a little bit of JS code, for IE7-IE8 browser, we only need to care about the input itself, global delegate click, let single check box input class name and checked state is consistent on it, Leave the rest to the CSS selectors. The total amount of code is basically the same as the API parameter in the screenshot above, and is more friendly to designers and page refactorers.

Engineering thinking, a high degree of logical thinking and abstraction, and a wonderful sense of the creator seem to make developers eager to design and encapsulate apis, never knowing when new technologies emerge or when they find other, simpler implementations. Those so-called packaging is so cumbersome and weak.

“Good, you don’t say, I change still can’t?” Components are things that are easy to go from small to large, forward compatible; You want to go from big to small, I can only laugh. Or wait for the next brand new version, or some completely unrelated project, bro!

2. The unpredictable UI layer

The development of modern Web technology gives us more choices in UI presentation. This poses a great challenge to the abstraction and encapsulation of the UI part of web components. Take a look at some of the comments from the industry:

If a component is confident that it abstracts and encapsulates the UI layer perfectly, this indicates that the component is already limiting the performance of the UI layer. This is no doubt, some things themselves are contradictory, engineering is to strive for consistency, but personalized is obviously inconsistent, and UI performance is a very personalized thing. So,…

Current Web components respond to new UI presentation requirements of new projects by either repackaging them with a new wrapper or writing more code for redundancy. Well, it’s not a good idea, but there’s no way.

3. Cross-departmental cooperation

Recently, we completed a project. The quality of the project is very high, and the reviews from all parties are very good in terms of UI, interaction and experience. Later, when we started a new and relatively large project, we wanted to borrow many good things from the existing project. The design is the same, but the front end team is different. Ideally, the front-end team of the new project will directly use the front-end UI components of the previous project (except the color and size are exactly the same), and the variable file color of less will be changed and transferred seamlessly every minute. How great!

However, as a result, the new front-end team abandoned the previous project’s front-end solution and went back to their own simple approach, SeaJS + jQuery +…

You might be wondering, gee, why not use something that’s already there? The main reason is the cost of getting started and learning. On the enterprise side, the front-end component system can compete with Kissy. It is object-oriented, modular and loaded on demand, and the API package is perfect. However, his team internal new someone with, someone to teach, can slowly start. However, you can delegate your set of things to other teams, given their magnitude and complexity, and the urgency of the project; It’s pretty daunting to see how many API parameters you have. There are also significant differences in code style, patterns, and so on.

Why are there so many apis?

It’s an interesting question: “Why are there so many apis?” This is an excellent question. When the original component was born, there were not so many apis. Later, the existing API could not meet the use scenarios of some UI layer or interaction layer, so the front-end development abstracted and added an API to meet this requirement. But the projects are one after another, and the needs are ever-changing. It wasn’t long before another requirement came along, the developers argued, couldn’t block it, and as a result, an API was added to the component. Over time, you have now seen a number of API parameters, at which point the Web component can be called a “mature Web component,” advertised as “suitable for multiple application scenarios.” It’s funny how adaptability can be achieved by adding apis, adding component code, and patting yourself on the back. I’m starting to see why 600 + lines of JS code are required for a little checkbox emulation component.

At the end of the day, it’s the component writing mentality of “abstracting and encapsulating component apis as much as possible” that has really gone against the trend.

We seem to need to think differently.

Three, conversion of thinking, separation and semi-encapsulation

It is well known that YUI has been out of maintenance for some time. As for the reason, I don’t know if you have a good look at it (see below comments) :

As I said, the design philosophy of encapsulation to meet UI needs inevitably leads to web components getting bigger and more bloated; At the same time, the front-end development role due to concerns and job span, the UI layer processing ability and its processing ability to the JS language itself is quite a gap.

Therefore, we must make appropriate changes for future development. I personally think there are two ways to seek change: separation and semi-encapsulation.

Separation of 1.

In fact, current UI components are also separate, and many styles can be controlled by class names. However, these separations are unavoidable, as with Autocomplete’s list styles, you can’t inline every list with the same style. However, if possible, style control is done in JS, such as Autocomplete’s list container size, positioning, hierarchy, etc. Some components even have complete CSS code embedded directly.

This design is designed to be packaged enough to make it easy to call. But UI friendliness is probably not the designer’s concern.

Obviously, the “separation” here is a step further than the traditional “forced separation”. There are two aspects:

Style control is separated from JS

②. Parameter source is separated from JS

The above separation, save JS code is small, the greater significance lies in the release of UI designers and UI engineers potential, so that all upstream and downstream member roles are involved in the construction of web components, as long as the designer’s design ability > development, page reconstruction personnel reconstruction ability > development, the quality of this component, It’s definitely going to be higher quality than front-end development alone. Moreover, it is more adaptable to other projects with different UI styles.

2. Half encapsulation

When it comes to Web components, encapsulation is a natural association. Yeah, how can you call it a component if you don’t wrap it? Now, we need to shift our thinking and semi-encapsulate components if we want to keep up with the increasing demands of the UI layer without the components becoming bloated.

Which begs the question, what is “semi-encapsulation”?

“Semi-encapsulation” means we only encapsulate things at the language level and at the functional level; For the UI layer, although it is ALSO JS, we treat it according to the thinking of CSS, mainly to meet the UI needs of the current project, not focusing on packaging and API design, and keep active at any time. Both UI engineers and front-end development can adjust it according to the specific needs of specific projects.

It should be noted that this “semi-encapsulation” is for different design styles of the project, for a specific project, its Web components or complete encapsulation, or mature API interface, small white development can be directly used, but not directly applied to other projects!

Separation, and semi-encapsulation are shown schematically:

The corresponding position participation is as follows:

As you can see from the figure above, the current misallocation of Web components (see GIF below) that I dissected in The first chapter is nicely addressed. Web component style control CSS, as well as non-encapsulated HTML structure, class name and so on greatly improve the partial design of the front end of the component construction participation, the improvement of component design quality, very helpful.

About semi-encapsulation of Web components

For development-minded programmers, this idea of “semi-encapsulation” may be unacceptable. I COW, every project, we need to repair the components, how to calculate the labor cost? If you support 10 projects, you have 10 sub-components. What about future maintenance?

About labor cost: traditional Web components are repackaged by front-end development on the basis of original components into web components needed by the project. This cost is actually no different from a small portion of UI layer content in the code of direct moving components, which will be mentioned again in the next chapter.

About maintenance cost: First of all, for each specific project, the component is universal, but semi-encapsulated, but for other projects, it is still a fully encapsulated Web component for specific projects, and the maintenance cost of traditional Web components is exactly the same;

Second, the semi-encapsulated Web components, the unwrapped part is the changeable UI layer, the overall structure is still object-oriented development, and the rest is still modular loading, so that what looks like 10 sub-components are really just 10 sub-components related to the UI layout closely aligned with the actual project. Remember, the UI layer is supposed to be specific by nature, and standing alone reduces the likelihood of style adjustments causing conflicts.

Finally, the components themselves should be independent, decoupled, and unrelated to each other for different projects. For example, 10 projects are using jQuery. One project needs to use a new feature of jQuery, so they all like to upgrade 2.0. Do other projects need to upgrade as well? Obviously not recommended, right? Newer versions of the browser may have different compatibility, and some of the older apis may have been removed. The same is true of jQuery. When we actually develop jQuery, 10 projects are actually 10 components. Although it looks like the code is the same, we still need to maintain it independently.

Therefore, to sum up, there is no increase in future maintenance costs.

The only problem with semi-encapsulated Web components is that they are unfriendly to small white practitioners. Many newcomers are nature’s code porters, hoping that components are silly enough to simply introduce a JS file and the functionality they want will appear. This is why we usually see open source Web components on the Internet are well packaged, you use trouble, which small white will use! At the same time, because of the need to consider a variety of application scenarios, there are many apis, components are very heavy, for the sake of publicity, can only be called powerful, suitable for various scenarios. Just as no action is best, no use is best for all situations.

When we work in an enterprise, the first thing we should consider is the quality of the components themselves, the quality of the product and the quality of the project. As for open source, is it too far?

We have professional and lovely colleagues, why should we treat our cooperative colleagues as little people, instead of giving full play to their respective strengths and making our products great together? ?

For example, last

As I was writing to this point, senior visual designer J asked me about the date and time selection component and the following sentence came up:

Online to find the date on which the time to choose good web components are encapsulated web components, for to the design of the small white didn’t require user or a few small factory is very friendly, but, for the use of design attaches great importance to the scene, the so-called “full package” has become a kind of restriction, not to mention the component class class name style specification is in line with the team.

In fact, what we want to modularize or componentize is an algorithm for date filtering or sorting. For the UI layer, you integrate a lot and get it over with. The end result? Rejected by designers! In fact, the HTML build is also hated by HTML engineers! Then, by a twist of fate, the designers accepted a time picker component that didn’t support IE7.

As you are reading, what would you do in such a situation? Wouldn’t it be nice if we had a semi-encapsulated Web component, where the UI layer content and the module layer content were clear and separate, so that UI engineers could concentrate on the UI layer content and satisfy any particular designer’s needs? !

Fourth, design oriented advanced customization product components

What kind of products are high-end, classy and stand out?

We can answer the above question using clothing as a model.

Obviously, custom-made clothes are more classy and of higher quality than clothes made on an assembly line.

Fully packaged Web components, like clothes on an assembly line, are industrialised, efficient and cost effective. However, the grade and quality of products produced by such Web components is rather crude. Semi-packaged Web components, which this article has repeatedly touted, emphasize tailor-made design, tailor-made interaction, and make our Web sites look like custom-made couture gowns. Stand out in the crowd of products, win the word of mouth.

It is important to understand that personal customization does not mean the complete abandonment of industrial, template things. Even if you let Magnolia design high-end dress for you, the production process of the dress, or will use line draft, sample and so on. It’s just not completely streamlined. The same is true of design-oriented semi-encapsulated Web components, where we still need object orientation, modular loading, generic event handling, and so on, but it becomes part of the story rather than the whole story.

Now let’s look at a very interesting problem, the initial development cost problem.

In the face of design requirements, we used to do things like this: Web components do not move, specific to the project, common. The current approach is to take a customized approach, tinkering with uI-related content in the original Web components based on design requirements. The differences are shown in the following schematic diagram:

All need to do some work in order to meet the needs of the UI, so the upfront work cost is not easy to estimate. However, it is certain that the amount of CODE in JS is much lower, and the UI is much more customizable for design, and the quality of the Web component is much higher if you have a lot of good designers on the team.

The contradiction between individual design and industrial production

Every enterprise should have its own product, and they all hope that the quality of this product is superior to others in all aspects. Yes, it is the quality of all aspects, so as to be competitive. Tencent values product quality more.

We have a lot of top product managers and interaction/visual designers, design web controls that are beautiful and elegant and user-friendly, a lot of micro-innovation in detail, a high quality product that has a prerequisite for production, but only a prerequisite, and the final presentation needs to be developed.

Visible, the development of students in the grasp of product quality is how important.

Every IT company has a developer or group of developers who want their code to change the world and appeal to girls. They want to free up productivity and improve efficiency through code production tools and the like; They want their code to be bug-free and perform like no other.

As we’ve said before, it’s both a strength and a limitation. The nature of reuse is engraved in our bones. Although the center understands that design is very important, designers always laugh bitterly at the realization of design effect. Why?

This is paradoxical because good development is about code reuse and performance, whereas personalized design is about being different and avoiding reuse. So, dear students development, if your team is of good design (if the design with a level, you ignore this sentence), in order to product high quality output, we must have a strong design oriented development thoughts, first of all, the first point is to be able to accept psychological, basically can’t reuse web components between individual projects; Secondly, in action, I am willing to spend some extra efforts and thoughts to carve out the details of the design.

When the final high-quality products come out, the heart will be very full will be proud, you will find yourself with considerable growth, the designer MM seems to be more friendly to you, with you say more than before.

Examples and complementary knives

Just last month, we finished the customization of a color picker. Here we would like to share which ones need advanced customization and which ones are used in accordance with modularization. First, here is the design:

First of all, this color picker is so specific that you can’t find a second color picker component online that looks like this. Therefore, advocating natural porters, you can wash and sleep first. Although there are many color picker components available online, I’ve seen their implementation and have to say, it’s not very good. Therefore, in order to restore the design quality and ensure the quality of the component code, it is easy and quick to customize.

First, we need to separate UI content from component module content. Module contents include: Dropdown component (including boundary judgment), color conversion module (HSL, RGB, HEX format color conversion); The rest is the UI layer content, which needs to be customized. Yes, this component requires a lot more customization than a typical component. Based on the amount of code, it’s 50-50.

Once again, it’s important to get rid of the outdated idea of “don’t touch the code inside the web component once it’s done”. There are still some extra costs that need to be paid to satisfy the design, but what used to be done outside is now done inside.

As for the specific division of labor, depending on the team structure, each person is good at different areas.

Well, it’s necessary to put it in bold here: Just as dress customization requires skilled garment workers, web components that want a design-oriented haute couture strategy must have similarly skilled front end personnel on the team, otherwise there will be very high and uneconomical customization costs.

5. Real knowledge comes from practice

Nearly two months later…

As mentioned earlier, designer Jerry consulted the date and time selection component. Later, some butterflies came out of the air and I implemented the date and time selection component. Based on the design-oriented semi-encapsulation concept, how did I implement it?

1. API separation – go back to the roots of UI components – HTML
   
   As you all know, HTML5 itself is similardate.datetimeThe type ofinputControl, such as Chrome will automatically call its own time selection control:UI components are nothing more than the set of things that implement a unified and compatible browser that fits the product ethos. Taoism is all about going back to the roots, and from that philosophical point of view, using a browser and HTML5 to standardize the set of interactive experiences must be the best practice. Traditional verbose JS and various apis go against The Times and are destined to become a thing of the past. Therefore, THE date and time selection component I implement here is based on native specification HTML5inputElement implementation, yes, onlyinputElements. Specifically include:

   Each type list corresponds to a time selection panel. For example, select year, and select month (final screenshot) :

   

   Not only that, the optional time range, and even the span of time selection, is done through HTML native property Settings. The value includes min, Max, and step.

   Min corresponds to the startDate API of the traditional date component, Max corresponds to endDate, and value corresponds to initDate.

   Here, we give the category to type, the scope to min/ Max, and separate it from JS to HTML. This increases the readability and accessibility of components, while slimming down our components to focus on presentation itself.

   As a result, our component API is very concise, requires only an onShow()/onHide() callback, is much more formal to use (due to the HTML5 specification), and is much cheaper to remember and learn. The best part is that we just instantiate common.js globally, for example:

   $('input').each(function() { var type = $(this).attr('type'); if (/^date|year|month|time|hour|minute|date\-range$/.test(type)) { new DateTime($(this)); }});

   For all the other sub-pages, you don’t need extra JS, set up extra apis. As long as the HTML content is written in accordance with the HTML5 specification, the date and time selection function is displayed there.

   Don’t work too easy!

   What? Select the date of the callback?

   The user only needs to care about the input element itself. Just as with the native input element, bind it with the change event, which is automatically triggered when the date in the text box changes. It can be said that the functionality of our pages can be used without the UI component, which is a qualitative improvement in accessibility given to HTML by API separation.

2. Advanced customization for UI design
   
   UI layer things are very variable, you can not say that you write a component, all teams, all scenarios, how big your component, how much logic judgment ha! Not for a single project, we need a solid core, and on top of that, uI-oriented advanced customization. One panel that is difficult to implement for date and time selection is date range selection, something like this:In fact, it is not difficult to implement a universal component with this function. We can also find it on the Internet. However, if you look at the designer’s handling of the selection details, it is hard to find a component that can satisfy such a UI design. What about the details? Include:
   1. Independently selected vacuum;
      
      
   2. Non-head and tail selected solid color;
      
      
   3. Head and tail selected half right Angle and half rounded corner;
      
      
   4. If head and tail are selected on the edge and folded, top to the edge and half open;
      
      
   5. Head and tail selected in the edge does not fold line is not top to the edge;
      
      
   6. Normal area square, select top to edge.
      
      
   7. …

   How to do? Obviously, with such a UI, we need to make simple customizations to the component’s internal implementation. The main customizations include:

   1. Generic class name
   2. Select the state class name
   3. Select the start class name
   4. Select the end class name
   5. At the beginning of the name of the class
   6. At the end of the name of the class
   7. The day of the week corresponds to the column class name

   Thus, in extreme cases, so many class names can appear at once:

   

   If we were a normal date picker, just two class names would work:.ui_date_item and.selected. However, when we are faced with a very refined style of UI components, we have to customize some class names for the design amount to help us achieve our presentation layer effect. Such costs are necessary and necessary.

   Ask questions? Do we still need to deal with national holidays (including Saturday and Sunday)?

   In terms of the power of the component itself, support is more important, but in fact, it is only the feeling of the developer. Modern components are lightweight and flexible. If the project does not have such requirements, there is no need to do similar processing. If there is a later requirement, we will deal with it.

   This way of thinking is different from the traditional way of thinking: “I need to think about various usage scenarios and make a rich and powerful component.” It’s “WHATEVER the UI layer needs, I’ll code it, minimize the APIS, and only think about common scenarios and leave out rare ones.”

3. Modular component A common positioning module of a component architecture. Each type of panel inside the time selector is also an independent module, which can be called independently or switched from other panels.

Six, the final summary

1. In order to maximize the quality of components, components to achieve the division of labor;
2. To division of labor, need to component UI layer things from JS out, play CSS/HTML engineers in UI processing attainments;
3. Stripping requires semi-encapsulation of components, avoiding large and complete apis.
4. The so-called semi-encapsulation is function encapsulation, not UI encapsulation; But for a specific project, the components are still fully encapsulated;
5. Ways to avoid apis include handing over native HTML attribute apis and designing apis based on project UI scenarios, rather than using meaningless and obscure scenario apis.
6. Use CSS to its full potential and avoid using JS to do some of your own functions.
7. Design-oriented component building is only appropriate for strategic projects, or projects that want to be boutique, and require good design and UI development. Otherwise, traditional large and complete components are more suitable.
8. The essence of UI components is HTML and CSS, JS is just auxiliary, don’t mess with the priorities.

What we end up with is an advanced web component with a well-designed UI, lightweight and compact code, and a modular management approach that qualitatively improves the quality of the entire project.

OK, so these are my thoughts and reflections on Web components, maybe a little wordy (click here for the summary version), I hope it won’t affect the central message. In addition, if you have any thoughts after reading this, or have some thoughts on web components yourself, please leave a comment.

Finally, thanks for reading!