Native HTML-based UI component development-

This article is a straightforward version. I. design idea of HTML-based development components II. UI component development based on native HTML III. Benefits of HTML-oriented UI component development IV. Summary ...,. This article is a straightforward version. If you want to see a passionate and thoughtful version, you can go to ISUX official blog: "The trend is, HTML development and UI component design evolution" and leave a comment.

　　I. design idea of HTML-based components

If you want to know what the native HTML-based UI component development is, click here: the native html ui component experience demo

Click the demo above to go to an ordinary static page. A common form is introduced, and the UI in it is default by the system. The HTML function is also native.

For example:

• Title prompt

• Select date

• Click Submit Form Verification

Although the UI is original, its functions are sound.

For example:

• Price impact of male and female style, city and transportation insurance

• Form submission event

The following is a miracle. click the button on the demo page (shown in) to load and initialize the UI component resources of a Project:

As a result, the original rough interface on the page suddenly becomes like this:

The ugly duckling turned into a white swan, including the original HTML function.

For example:

• Title prompt

• Select date

• Click Submit Form Verification

However, the most important thing and the most amazing thing is: We just introduced some CSS and JS components of the UI, right, just introduction and initialization, without a trace of business JS. however, the previous interaction functions are completely unaffected, but the experience is on the second floor!

See the following gif Demo:

The reason why the UI component can be completely separated from the business-related JavaScript, and can be seamlessly integrated. This is because the design concept is implemented based on the native HTML, so that the UI component can return to its essence or its role-UI.

　2. Development of native HTML-based UI Components

Solve two questions:

1. Why can I develop UI components based on native HTML?

2. How to Develop UI components based on native HTML?

1. Why UI component development based on native HTML?

There are many native UI representations in HTML. The UI representation of UI components is essentially similar. The difference lies only in the rough and exquisite looks.

For example, the title prompt is displayed. The browser uses the title attribute by default. The length is as follows:

The tips component designed by the designer is a small black style, as shown below:

The two are actually two things with the same effect. The difference is only that -- UI. Therefore, we can fully implement our tips prompt effect based on the native title attribute. By taking advantage of the same nature, what changes is just what it looks like.

Another interesting example is form verification. In HTML5, the form has built-in verification by default. It is based on HTML native attributes such as type, required, pattern, max, and min and comes with the UI (Chrome effect under win, other browsers in other systems look different ):

The UI format determined by the team:

Similarly, the nature of verification is similar, and the form of interaction is similar, not just the UI. Therefore, we can fully implement our form verification Effect Based on native HTML verification rules. By taking advantage of the same nature, what changes is just what it looks like.

Many other UI components are similar.

Isn't it the most reasonable strategy to reuse the previous soul when we want to change only the appearance?

2. How to develop UI components based on native HTML?

There are two key points: ① API parameters are directly taken from HTML; ② callback directly triggers native events;

Let's take the date and time selector mentioned above as an example.

The mainstream implementation of the date selector is basically as follows:

new DatePicker($("#date"), {  type: "date",  initDate: ..,  beginDate: ..,  endDate: ..,  onSelected: $.noop});

API parameters. All event Callbacks are derived from JS parameters.

The implementation of the HTML-oriented design philosophy is:

new DateTime($("[type=date]");

All API parameters are taken from HTML, and the JS Code is only global initialization (covering all time controls at one time ). The type attribute in HTML corresponds to the type API in JS, the value attribute value corresponds to the initDate value, and min/max corresponds to beginDate/endDate respectively. the onSelected callback is implemented through the native change time in the trigger input box.

As a result, other front-end partners can develop based on the native HTML attributes and events during development, so as to achieve seamless connection between business JS and UI components at zero cost.

　3. Benefits of HTML-oriented UI component development

1. Semantics, accessibility, SEO, etc;

2. Low learning cost;

3. Focus on HTML controls rather than components;

4. It can be processed globally at one time;

1. semantic and accessible

After all, it is developed based on native HTML.

2. Lower learning costs

You don't need to remember the different js api names, just remember the standard HTML5 attributes, which in turn helps some front-end developers learn HTML.

Low learning costs are very helpful for cross-team collaboration. Other teams are happy to use your things, get involved quickly, and achieve good results. On the contrary, Apis vary widely. Every time you use them, you must go through the documentation, which definitely affects cooperation.

However, in practice, I did not consider the learning cost, that is, the learning cost of transforming the way of thinking. In fact, we only need to develop HTML elements for elements. However, if you have any friends, you still need to write articles on the UI component elements generated in the old way of thinking.

　　

3. Focus on HTML controls rather than Components

For example, if the date selector is modified, what should we do? directly:

$("input").change(function() {});

To modify the date range, directly:

$("input").attr({  "min": "2015-12-27",  "max": "2016-12-27"});

The UI component is automatically synchronized. There is no JS Code related to components, and there is nothing to learn about. There is no so-called high-rise architecture. It is a simple and basic HTML operation. Isn't this kind of development easy to use, and even the users of the White House can get started?

As a result, the progress of front-end development is not affected by the development of UI components when multiple teams work together for collaborative development. For HTML-oriented development, you can focus on your own business development.

As a result, the frontend separation is a thing that sounds terrible.

In addition, there are a lot of development in the factory, responsible for internal projects, write JS is good at business function implementation, but the UI is a weakness. OK. At this time, the UI component system for HTML development is its savior, right? Directly introduce CSS and JS and perform simple global initialization (there may be some simple fine-tuning ), as a result, the page is very tall. Is it very useful!

4. One-time global processing is supported.

In traditional implementation, the script for each specific business needs to participate in the specific API parameter settings of the UI component. While HTML-oriented implementation, API implementation and specific business pages, as long as the project's common. perform global initialization in js, as shown in the following code: Select. init (), the JS Code related to the UI component is no longer required in a specific business JS file (in most cases.

The JS Code at the UI Layer is separated from the JS Code at the business layer to achieve further "frontend separation" and decoupling. It will be of great benefit for future maintenance and upgrade.

　　Iv. Summary

This article focuses on the design ideas. As for the specific technical details, we will share the ideas with you later. The simpler the finished product, the more accumulation required.

However, now I have to re-evaluate the implementation of the UI component, but there are still some regrets, mainly because, the implementation of the three layers of HTML layer> data layer> presentation layer is not clear. At present, there are no problems with the HTML layer and the presentation layer. However, the data layer does not fully penetrate the entire UI component system, resulting in, this UI component system does not attract developers who are paranoid about JSON data and respond to potential extreme demands.

However, don't worry. Next year, that is, 16 years, I will further enhance the component design. First, I will not consider the IE7 browser, so there will be more things to do. Second, the clear data layer serves as the middle layer for code refactoring.

The above is the content developed based on the UI component of native HTML. For more information, see PHP Chinese Web (www.php1.cn )!