Thoughts and explorations on web front-end development

First, Introduction

First of all these years on the front-end technology in endlessly, from the earliest only with JS to do simple verification, and now found it seems that the front end is omnipotent feeling. Especially in order to reduce the front-end development complexity, the emergence of a large number of MVC/MVVM model of the front-end framework, constantly refresh our code organization structure and development model, such as: Backbonejs, Emberjs, Knockoutjs, Avalonjs (domestic), AngularJS, Reactjs and so on.

Ii. existing Mainstream framework

Our development model The first revolution should be made from Google Ajax until Nodejs change is very big, we are also trying to find a more reasonable and simpler and more suitable development model. I myself also experienced the development from native JS to using jquery to manipulate the DOM, and then to apply Knockoutjs, Avalonjs, Angularjs and Reactjs to our projects (Backbonejs, Emberjs, Polymer I didn't actually use it), we found that our program is more simple and more interesting. But the focus of each framework is different, and there are some drawbacks:
1, Angularjs, bulky too complex is not suitable for lightweight applications, and I 1.3 give up IE8 and 2.0 leap development brooding, finally began to focus on Reactjs.
2, Reactjs, the study of a period of time to find really good, the first is relatively light weight, performance is also very good, the most important is the concept of virtual DOM, I think it is an innovation, but it is not really a framework, its focus is to build the UI, Just like Ng's directive a grade, so a lot of things have to be done by themselves, it can only be a tool for us to structure a complex application also requires a lot of work. Another thing is that I don't like the jsx of it, although it can be processed on the server side. It should be my personal prejudice.
3, Polymer concept is very advanced, based on the implementation of Web Component, I personally think this is the future trend.
But for now, the compatibility of browsers for Shadow DOM: http://caniuse.mojijs.com/Home/Html/item/key/shadowdom/ Index.html, I reckon no one would want to use it in addition to the study, and it took advantage of HTML5 's imports:http://www.html5rocks.com/en/tutorials/webcomponents/imports/, The problem with this pattern is very obvious, that is, the need to import too much HTML, but also the concept of nesting, it can be imagined.

Third, the idea of the front-end framework

These frameworks are strong, but I think the actual development, a good framework should be the existing libraries, plug-ins and so on these perfect combination, and provide a simple interface and reasonable code organization structure, The existing jquery plugins are much more (in fact, jquery is much more popular than these), and we can use many of the existing open source libraries. My idea is that the existing resources should be fully utilized. So I want to make a whole frame out of myself. I conceived a design under:

1, Web Component ideas, combined with Shadow Dom and virtual DOM, if support Shadom DOM use Shadom dom otherwise use Virtual DOM implementation.
2, the control definition as simple as possible to understand, can quickly wrap the existing plug-in, the control has the concept of inheritance, the control has a small number of modifications can be considered in the way of inheritance overwrite implementation.
3, the two-way binding to achieve MVVM, is actually three (actual DOM, the control instance (either SHADW or virtual to a virtual DOM), data)

For the time being, I call this project chitu.js, the Red Rabbit js, and then put it on GitHub.

Iv. refinement and realization of ideas

1. Label definition
For example, we need a Hello control

<  ID= "Id1"  binding = "Hello1" ></ Hello >

2. Control definition
We define the control of Hello

Chitu.component (' Hello ',function(self) {//Property DefinitionSelf.name ={get:function() {returnSelf.root.getAttribute ("name"); }, set:function(value) {Self.root.setAttribute ("name", value);    }    }; Self.value={get:function() {returnSelf.root.innerText;}, set:function(value) {Self.root.innerText =value;}    }; //...    //Event DefinitionSelf.onclick =function(){    }; //...    //method DefinitionSelf.setcolor =function(color) {Self.root.style.color=color;    }; //...    //Control GenerationSelf.render =function () {        //...        varText =document.createTextNode (Self.value); returntext;    }; //Control diesSelf.dispose =function(){    };});

Here is the definition of the entire Hello control, that is, the Hello control instance as a virtual node, this is the idea of Reactjs, but the implementation above if it is supported Shadow DOM can be used to put the returned node in render into the shadow dom.

The two-way connection between the control property and the actual DOM is achieved by introducing the Get Set method, which in fact requires a complie processing to get The set method is converted to a property by ES5 's Object.defineproperty method (compatibility is not considered first).

This is a very easy place to integrate jquery controls, such as a ComboBox control:

function (self) {    = {        get:function() {return $ (root). ComboBox (' GetValue ');} ,        set:function(value) {$ (Root). ComboBox (' SetValue ', value);}    };        function () {        $ (root). combobox (options);         return root;    };     function () {        $ (root). ComboBox (' Dispose ');    };});

If the control requires inheritance, you can define a Mygridex inheritance Mygrid control

function (self) {    // Overwrite property    self.attr1 = {        get:function() {},        Set: function (){}    };         // Overwrite method    function () {    }}, 'mygrid ');

3. Controller

Chitu.controller (' Ctrl1 ',function(scope) {Scope.data={tenant_id:' 001 ', Tenant_name:' Tenantname ', Height:100    }; Scope.hello={name:' Helloname ', Value:' World '} scope.grid1={width:500, Height:' {data.height} ', Rowclick:function(row) {scope.vdom.id1.value = Row.name;    }    }; Scope.search1={text:' {data.teannt_name} ', Searchclick:function(){                    }    };});

Here you need to explain the following <Hello id= "Id1" binding= "Hello1"></ Hello>

The binding here actually corresponds to the property in the controller, which is actually the option parameter of the control, when we previously called the jquery control

$ (' #id '). Jqgrid ({    // a bunch of parameters });

In this case, this heap of parameters can be linked to the page through a binding, convenient for the use of the control, of course, the definition of the control can be defined as a lot of default parameters, only need to pass the parameters to change.
Of course, our parameters are not necessarily written in the binding, you can also bind control properties separately

<HelloID= "Id1"[value]= "World" ></Hello><HelloID= "Id1"[value]= "{data.tenant_name}" ></Hello><HelloID= "Id1"binding= "Hello1"[value]= "World" [onclick]= "Search1.searchclick" ></Hello>

The first line: there is no corresponding binding attribute, there is only one value property, value is world
Second line: value is bound to the Data.tenant_name data in the controller in two directions
The third line: The value is first taken from the hello1 of the bindig, and if there is [value], the original value is overwritten

This is why the attribute is added [brackets], because it is possible to name any property, and to avoid conflicts with the original DOM attribute.

There's one more thing in the control. It's worth saying that we can focus our data on Scope.data.
1, other local bindings only need {Data.row1.field1} so specify the binding is good
2, we can not need to first data in the structure of how, according to the binding relationship to generate data structure
3, in most cases we retrieve the data is a return to result, we directly assigned to Scope.data can, do not need hello1.value = result.name, grid1.data = result.list;
4, we need to submit data, but also only need to take from data, very convenient

Of course, for ordinary labels, we can also bind.

<[title][text]= "{data.text}"   [onclick]= " Search1.searchclick "></div>

In this way, our code may be focused on some of the controller's methods currently, we can directly get to each control instance in the controller, you can directly access the control's individual properties to achieve interaction.

Of course, if you have a binding to the data data, you can also interact with the UI by manipulating it directly.

V. Possible problems and explorations

I gave you a description of my ideas and ideas, and we will analyze the problems we may face.
1. Compatibility
At present only in the trial stage, many problems have not met, my goal is to try to do ie8+
2. Performance
The consumption of performance may be mainly due to node scanning, control render, attribute binding, and frequent refresh of properties. The node scan will certainly be a bit of a drain, but the convenience of it can ignore its consumption, unless you want a control to specify to call manually, the control render depends on the control you write, not the framework of the problem, property binding in the amount of data is not large to a certain extent is basically no problem.
3. Development efficiency
The main development efficiency depends on whether the separation of concerns, the code organization is clear and reasonable and simple to understand, the code only need to write something change, the repeated details are encapsulated together, this can only be done as far as possible.

Some of the other ideas about me

1, need not introduce CSS-like things to separate the binding between the page and controller, this can also remove the node scan, improve performance, as follows

var binding={    ' #id ': ' Todo1 ',    ' #grid1 ': ' Grid ',    ' #hello1 ': ' Hello ' };

2. About render Processing
A, implemented in code (native, jquery)
b, template implementation or stitching strings
C, by pre-generated (similar to JSX, can also be Nodejs C # Java and other languages)

3. About Property Refresh
Because the control property is directly bound to the native DOM, if a large number of property refreshes are causing performance problems, consider whether a parameter is used to turn off (immediate refresh, one-time refresh)

4. Combined with AMD CMD
This is not a problem, and if the control is wrapped in a third-party control, it can be more convenient to implement dynamic loading.

5, whether to introduce other features, such as NG injection characteristics, filters, etc.

6, which links can also be pre-processing on the service side

Vi. concluding remarks

At present, I have just a thought, there are many problems may not be specific to think clearly, now I realized a simple version, and so I first toss out a 0.1 version on GitHub, if interested friends, can join together design ideas and development. Everyone has good ideas, suggestions welcome to my message.

Thoughts and explorations on web front-end development