Students who have been engaged in the front end for a long time will know one thing, that is HTC（HTML Components） , the name of this thing is very Web Components , but they are two different things. Their ideas have many similarities, but the former is already a yellow flower yesterday. , The latter is in the ascendant, what caused this gap between them?
Some features of HTML Components
Because only IE supported HTC mainstream browsers, many people subconsciously think that it is not standard, but in fact it also has standard documents, and there are still links to it, pay attention to its time!
http://www.w3.org/TR/NOTE-HTMLComponents
Let's take a look at what it can mainly do?
It can be introduced into the HTML page in two ways, one is to be attached to an element as a "behavior" and CSS ; the other is as a "component" to extend the label system of HTML
behavior
Behavior ( Behavior ) is IE5 , mainly to separate document structure and behavior, and isolate behavior in a similar style. The detailed introduction can be seen here:
http://msdn.microsoft.com/en-us/library/ms531079(v=vs.85).aspx
HTC file can be imported into the behavior, which is included in the HTC specification just now. We can extract it to make it clearer:
// engine.htc
<HTML xmlns:PUBLIC="urn:HTMLComponent">
<PUBLIC:EVENT NAME="onResultChange" ID="eventOnResultChange" />
<SCRIPT LANGUAGE="JScript">
function doCalc()
{
:
oEvent = createEventObject();
oEvent.result = sResult;
eventOnResultChange.fire (oEvent);
}<HTML xmlns:LK="urn:com.microsoft.htc.samples.calc">
<HEAD>
<STYLE>
LK\:CALC { behavior:url(engine.htc); }
</STYLE>
</HEAD>
<LK:CALC ID="myCalc" onResultChange="resultWindow.innerText=window.event.result">
<TABLE>
<TR><DIV ID="resultWindow" STYLE="border: '.025cm solid gray'" ALIGN=RIGHT>0.</DIV></TR>
<TR><TD><INPUT TYPE=BUTTON VALUE=" 7 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 8 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 9 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" / "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" C "></TD>
</TR>
<TR><TD><INPUT TYPE=BUTTON VALUE=" 4 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 5 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 6 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" * "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" % " DISABLED></TD>
</TR>
<TR><TD><INPUT TYPE=BUTTON VALUE=" 1 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 2 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" 3 "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" - "></TD>
<TD><INPUT TYPE=BUTTON VALUE="1/x" DISABLED></TD>
</TR>
<TR><TD><INPUT TYPE=BUTTON VALUE=" 0 "></TD>
<TD><INPUT TYPE=BUTTON VALUE="+/-"></TD>
<TD><INPUT TYPE=BUTTON VALUE=" . "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" + "></TD>
<TD><INPUT TYPE=BUTTON VALUE=" = "></TD>
</TR>
</TABLE>
</LK:CALC>
</HTML>This is an example of a calculator. Let's take a look at the code structure first. Is it clear? look at now with jQuery , how do we achieve this kind of thing: use the selector to select these buttons, and then add event handlers. Note that you have one more step in the selection process, and the whole process is a mixture of declarative and imperative code styles. If you follow it this way, all your JS is basically lost in isolated unrelated files, the whole is a configuration process, and the separation is very clean.
In addition to this calculator, there are also examples of changing the interface display or adding animations in the specification documents. Note that their entry points are equivalent to the behavior of attaching to a specific selected element, even if DOM does not expose any choices JS It has no effect, because they are directly linked to the element CSS
This kind of meaning is not obvious from the current point of view, and it is now widely used to select elements and then add events, which is also a good way to separate presentation and behavior.
But the other way of using it is different.
Component
HTML5 narrow sense bring us? It is a lot of new element tags, such as section，nav，acticle . What are the benefits of div implement these things directly? It lies in semantics.
so-called semantics of 1618e5e56422ee means that an element can clearly express what it is doing without ambiguity. Like div , it can be compared to a Object . It does not express anything specifically, but can be used as a variety of things. . and nav once written, you know that it is navigation, it is like class , which can express specific meaning.
So, the original HTML element is obviously not enough, because the actual development process to express things obviously far exceeds these elements, such as calendar, this kind of thing does not have an element to describe it, let alone some enterprise applications Complex controls such as trees that may appear in the.
Without providing native elements, the trouble for development is that the code is troublesome to write. For details, you can see a reply from my previous article. The third point:
http://www.zhihu.com/question/22426434/answer/21433867
angularjs ways to provide their own expansion elements. Now we know that the typical ones are 0618e5e5642333 and polymer , but they were not absent in the early days:
http://msdn.microsoft.com/en-us/library/ms531076(v=vs.85).aspx
Look, this is the HTC to add custom elements of 0618e5e5642356. Each element can define its own externally provided attributes, methods, and events. It can focus on implementing functions as if writing a new page inside. And you don’t find it. It takes a long-term view and provides a namespace to prevent you from introducing custom elements with the same name provided by two different organizations on one page.
This thing can be called a component, it is completely isolated from the outside world, the outside world can use it as long as it is used, just like using native elements, using selectors to select, set properties, call methods, add event handling, etc. , And, I noticed no, its attributes are get and set , what a dream thing!
It is precisely because it is so easy to use, so in that era, we used it to do a lot of things, encapsulated various basic controls, such as trees, data tables, date selection, etc., even at that time some people select browser’s native 0618e5e5642384 and radio not good-looking, with such a thing, pictures are encapsulated in it to simulate the function, instead of the original one.
There were also people at the time. For example, I thought about it in 2004. Can these be expanded and expanded to other than the basic controls, and the business components are also made like this. Everything is a component, how good?
But there are some things that I didn't understand until a long time later. Although business-based end-to-end components are easy to write, they have fatal flaws.
So far, HTML Components has come to an end, and there is no discussion about why it is gone. There is too much controversy here. I just want to talk about the need for a new standard that everyone has high expectations for Web Components What problems are facing.
Challenges of Web Components
I will list them one by one and explain them one by one. Some are already there, some are worse, some are not, no matter how much, let’s talk about what this thing should look like in my mind.
Custom element tags support namespace
The reason I have said before is that there may be components from different organizations that implement similar functions and exist in the same page, causing naming ambiguities. So I thought for a long time, but I still think it is better to have a prefix:
<yours:ComponentA></yours:ComponentA>
<his:ComponentA></his:ComponentA>Even, the prefix here can also be an abbreviated alias, such as yours=com.aaa.productA , which may only appear when it is complicated to a certain extent. Don’t think that this is too exaggerated, but one day the Web system will be able to build very large software. By then you will know Is it possible?
Style local scope
This some time ago some browser had achieved in the internal components, style plus a scoped property, this is the right direction. Why do you want to do this? The so-called components, the smaller the introduction cost, the better, and it can be introduced without agreement without causing problems. That is the best result.
If the style of a component is not partial, it is likely to conflict with the main interface. Even if you do not conflict with the main interface, how can you ensure that it does not conflict with the styles of other components contained in the main interface? Relying on naming conventions is unrealistic, but in the long run, when your system is big enough, this is a big problem.
Communication with the main document
A custom component should be able to communicate with the main document. This process includes two directions, each in a variety of different ways.
From the inside out
Except for events, there is really no good way to communicate in this direction, but events can also be defined in two ways, one is similar to onclick , the main document should be able to directly add corresponding event monitoring functions on it, just like As with native elements, each event can be used individually. The other is like postMessage , which only provides one channel, how to deal with it, and define the message format and processing method by yourself.
Both of these implementations are feasible, the latter is lazy, but it is sufficient, and the former has no obvious advantages.
From outside to inside
This can also be done in two ways. One is that the component exposes its properties or methods to the main document to call it, and the other is that it is also transmitted from the outside through postMessage . The former is more convenient to use, and the latter can also be used.
Therefore, if you are particularly lazy, this component will become like a iframe , basically interacting with the outside through postMessage
JavaScript
I am very entangled in writing here, because I finally came to the most controversial place. According to many people's thinking, I should also write JavaScript isolated as a local scope here, but it really doesn't work. We can first assume that all JavaScript inside the component are running in the local scope, and it cannot access the objects in the main document.
Let me explain the previous pit and why the end-to-end components are defective.
First explain what is end-to-end component. For example, I have a component that encapsulates a call to a certain back-end interface, as well as some display processing of its own, and communicates with the outside world through events. It does not need to rely on others as a whole. The initial loading data is done internally. It is also very simple for others to use it, just put it directly on the page.
In theory, this thing should be very good, so easy to use, what is wrong? Let me give you a scene.
There are multiple instances of this component on the page at the same time. Each component loads the initial data. Assuming that they have no parameters, the data loaded by each component is the same. Is there a wasteful request here? Some people may think that a little waste is not a problem, so continue.
Assuming that this component is a very common drop-down list, used to select the occupation of personnel, initially there may be doctors, teachers, police, etc., I put this component directly on the interface, and when it appears, I load the required The list information is displayed. There is another configuration interface for configuring these occupational information. At this time, I added a nurse in it and submitted it. Assuming that for data consistency, we push this change back to the page, and troubles arise.
When the interface has only one occupation drop-down list, it may be easy to handle. When there are multiple occupations, this updated strategy may be problematic.
If this push connection is done inside the component, there will be a problem of pushing multiple copies of consistent data to different instances of the component. If we put this outside, we also have two ways:
Subscription publishing mode, the component subscribes to a data source, the data source is connected to the server, and when the data changes, it is sent to each subscriber
Observer mode, the component observes a certain data source and retrieves it when the data changes
These two are very similar, no matter which, they all face a problem:
data source?
Obviously it can't be placed inside the component, it can only be placed in a "global" place, but what we just assumed is that the JavaScript code inside the component cannot access external objects, so...
But if it can be accessed, the isolation mechanism of the component is useless. The best way may be to support both, the default is local scope, and there is a special scope JS framework, but the browser implementation may be much more difficult.
Some people may say, why do you make the problem so complicated, and use such BT to create problems for our bright future. I think the problem is always to be faced. If you can face the problem before it is done, the result should be better.
I have observed the Web Components . Most of them are completely applauded, but some of them are mainly because the front-end MV* students have a conservative attitude towards it. The main reason should be the points I said. Because this group is mainly doing single-page applications, the problems encountered in this group are different from the traditional front-end.
So, for example, Angular , or React , where are their collaboration points Web Components I personally think that the engine is retained, and the upper part is gradually Web Components , so they are not a question of who eats which, but how to integrate them. In the end, there are two layers at the front end, one layer is the data and business logic layer, and the other layer is partial to UI . In that layer, there can be Web Components , which is very suitable.
Finally, I will talk about my Polymer . My opinion is not as crude as @司徒正美, but I agree with him, because Polymer is to make end-to-end components, which will face many challenges. Although it is a componentized framework, componentization is most suitable for solving large-scale collaboration problems, but if you look at the road to large-scale single-page applications, it is much React from the target Angular and 0618e5e564261e.
You Yuxi's Understanding
1. The Web Components in the Custom Elements specification in 0618e5e564268e must have a dash - , which basically plays the role of mandatory namespace. Link
2. Shadow DOM is local scope by default. Link
3. Communication
From the inside to the outside: the existing DOM event API is used.
From the outside to the inside: Polymer is to expose the public attributes ( attributes ), and then use MutationObserver to observe the changes of the attributes, and keep the corresponding synchronization between property and attribute In usage, it <input type="xxx" value="xxx"> like 0618e5e56426e9. As for dynamic data, the Web Components specification itself does not actually involve data binding and transmission, and the specific implementation is still executed by the framework.
4. The problem of data source, I think there is nothing particularly difficult, just define the shared part and constructor in a closure. Give a simple example:
(function () {
var sharedStore = new Store() // 共享的数据推送/抓取服务，可以包含缓存机制
var customElementProto = Object.create(HTMLElement.prototype)
customElementProto.createdCallback = function () {
this.data = sharedStore.fetch() // 调用共享的数据
}
document.registerElement('my-element', {
prototype: customElementProto
})
})()5. It needs to be clear that Web Components does not attempt to replace the responsibilities of the framework, but only provides a set of encapsulation mechanisms consistent with the DOM API Each component can use different implementations inside, but no matter what framework you use internally, the same API exposed to the outside. So you can in the framework A easily by the use of internal application framework written in B component implementation. One of the major problems of component reuse: the problem of incompatibility of the framework is smoothed out. Personally, this is the core meaning of Web Components For framework authors, there is no need to make major adjustments Web Component , only a convenience function for Web Component
6. Polymer and Web Components are not the same thing, Web Components is a set of specifications, and Polymer is a framework. Polymer itself is also divided into three parts:
- Smooth browser differences and achieve
Web Componentsspecificationpolyfill - Core framework. In fact, based on
DOMobject itselfMVVM, philosophy is "DOMisViewModel." - Additional component system based on the core framework.
At the level of the core framework, Polymer , Angular , React although their implementations are quite different, but from a functional point of view, they are actually the same.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。