Design what modules a JavaScript framework needs to write

Do you consider writing a frame of your own when this JS framework is running around? The following may be a bit helpful.

What should a framework contain?

1. Language extensions

Most of the existing frameworks provide this, and the language extension should be based on ECMAScript and should not be dependent on any hosting environment, i.e., as a framework designer, you should ensure that your language extension works in any hosting environment, not just in a browser environment. You have to make sure that it works correctly in environments such as Wscript,spidermonkey Shell,rhino shell,adobe extendscript Toolkit and even flash ActionScript. As a practical example, settimeout can't appear in it, and you can't run with XMLHTTP load scripts, even though they look very close to the language. Keeping this part of the independence allows you to easily transplant your framework into other hosting environments. Mengjin County Second Medium

2. Data structures and algorithms

JS itself provides a very limited number of built-in objects, many times, the framework should provide some data structures and algorithms to help users to better complete the logical expression. But I think that casually fan Ben data structure or algorithm book with JS to pick a few implementation of the framework is not responsible, most data structures should be in the form of libraries rather than frameworks. The data structures in the framework should be common enough and implementations are not very complex and can be considered such as collections, hash tables, linked lists, ordered arrays, and binary searches on ordered arrays. For JS, the object is a natural string hash table, and the collection is easy to implement on the Hashtable, so only the built-in method of dealing with object, we can implement an efficient collection or hash table.

3. Dom Extensions

JS is mainly used in web development, all the frameworks are also used in the browser environment, so the focus of the browser-side environment of the focus of the DOM is certainly the framework of the expansion of the target, if a framework does not provide the extension of the DOM, it is basically useless. It is important to note that DOM extensions are also standard in the web, so do not try to do strange extensions for various browsers, such as the prototype of the element below FF, and the creator of the framework should ignore them. One of the main tasks of the DOM extension is compatibility, where DOM implementations vary considerably from browser to viewer, and the framework must eliminate the differences in these implementations and provide a unified approach to access. Of course, as a framework, should provide some more convenient interface, the host provided by the DOM object with the JS object encapsulation is a good idea, but it is also likely to cause memory leaks, so before doing this, it is necessary to understand the memory leaks. In fact, the expansion of your imagination is far less than the design of a designer, for example, if you can implement XPath more fully, you can do better than jquery.

4. AJAX Extensions

Most of the existing frameworks appear because of Ajax, so if you want to design a popular framework, Ajax has to be done. Similar to DOM extensions, the main task of the Ajax extension is compatibility and memory leaks, XMLHttpRequest objects for the core components of Ajax, which must be created in IE6 with ActiveX, and there are various versions of ActiveX. The resulting memory leaks and compatibility becomes cumbersome, such as: event function name case, this point, and null assignment of event functions. On the basis of dealing with these compatibility, further work can be done to provide some common implementations. It should be noted that unless you are sure that the interface you provide is better than the original, do not change the interface of the original XMLHttpRequest object, such as writing a request function instead of open and send, if you are not sure why the experts are so designed, Please don't think of them as fools. I would like to write another compatible and memory-safe XMLHttpRequest into the namespace of my own framework, so that it looks exactly the same as the one described by the XMLHttpRequest from the outside. For XMLHttpRequest I think the only modification that can be considered is to provide the Onsuccess event. Of course AJAX extensions for some complex functions are also possible, such as htmlhttprequest extensions that allow Ajax beginners to like your framework.

5. Effects

Time effect is the most irritating to the user's nerves, fade, ease, sliding, color gradient these are very good, in fact, the technical difficulty is not very high. Drag effect is a very important browser effect, using mouse events to simulate the original is very easy, but compatibility and setcapture is also a very troublesome thing. This part of the content is possibilities and can be.

6. Script Management

Because people like C + + style include or Java-style import, many frameworks provide Ajax-based script management, but the efficiency of synchronous loading is huge. Before we have made a variety of attempts to find a browser without XMLHTTP loading external JS method, but the final conclusion is: it is impossible to think about this, a little thought can be known that Java C + + C # is a compiled language, include and import are compile-time processing, It is not possible to do something similar in JS. To achieve similar functionality, I think we can use a server-side program or write a text tool to implement it. Yui will all the JS file dependencies extracted from the practice is feasible, but this is not the implementation of the include, maintenance of dependency is not a very simple thing.

7. Controls

Ext's success tells us that providing quality controls is the framework's kingly way. You can't expect good expansion to attract more users. Most people only care about how to do the work at hand quickly. Of course not all frameworks have to provide this part of the content. Control depends on ability and artwork, but at least ensure that the controls in the framework do not leak memory.

Some principles of frame design

1. Don't do anything extra.

For this framework design, I think a very necessary principle is not to do superfluous things, to give an extreme example:

View Source print?

1	functionadd(a,b)

2

{

3	returna+b;

4

}

This code, if it appears in the frame, is a joke. However, most of the time, things are not so obvious, many frameworks try to "implement" OOP in JS in some form, but in fact, JS itself is oo (ECMA262, not as some people say is based on object and so on) just some syntax and Java and other languages. Then obviously these OOP "implementations" are actually the same as the above example. Another example is Array.prototype.clone:

View Source print?

1	Array.prototype.clone=function(){

2	returnthis.slice();

3

}

2. Use prototype extensions with caution

Many frameworks use prototype to modify native objects to do language extensions, but I think it should be taken care of, without a doubt that this will create some naming pollution, and you cannot guarantee that the user of the framework or other frameworks that coexist with your framework will not use the same name to accomplish other things. It is particularly important to note that the prototype extension of object and array are particularly dangerous, and for object, if object is modified, then the user of the framework will not be able to create a clean object that has not been modified, which is a fatal problem, Especially if your user likes to use for in to reflect the properties of an object. The danger of Array.prototype modification comes from JS a small design that does not know intentionally or unintentionally, and for the native array, the traversal result of the for and for in is the same in any case, and because the custom property cannot be enumerated because it is not controllable. Any Array.prototype modification will destroy this feature. On the one hand, I don't think it should be recommended to iterate over an array with for in, which contains the wrong semantics. On the other hand, the architect of the framework must respect these users, because it is the right approach for the syntax defined by the ECMA. It contains a simple fact: if you modify the Array.prototype in your framework, some of the code that worked correctly before is not working correctly. Modifying prototype directly looks tempting, but you should consider two possible scenarios before considering it:

Function: Provides a function that takes an object as the first argument such as Array.prototype.each =

View Source print?

1	functionForEach(arr,f)

2

{

3	if(arr instanceofArray)/*...*/;

4

}

Inheritance: Inherits a built-in object as return, such as considering array.prototype.each=>

View Source print?

1	functionArrayCollection()

2

{

3	varr=Array.apply(this,arguments);

4	r.each=function(){/*......*/};

5

returnr;

6

}

To apply a famous saying, do not modify the native object's prototype unless you think it is necessary. However, modifying the native object's prototype does have some special uses (that is, "necessary"), mainly in 2 points: Text volume support and chain expression. One example can reflect these two points:

View Source print?

1	varcf=functionf(a,b,c,d)

2

{

3	/*........*/

4	}.$curry(3,4).$curry(5).$run();

If you want to implement an expression like the one above, you may need to extend function.prototype, and if you think the cost of naming pollution is worthwhile, then it can be provided to the user.

A more flattering approach is to give the user the right to choose, and provide an extender:

View Source print?

1	functionFunctionExtend()

2

{

3	this.$curry=function(){/*......*/};

4	this.$run=function(){/*......*/};

5

}

If the user likes can functionextend.apply (Function.prototype); If you don't like the extension, you can

View Source print?

1	varr=function(){/*......*/};

2	FunctionExtend.apply(r);

3. Maintaining consistency with the native object

I wonder if you have noticed that the built-in object Function array has such properties: the new function () is exactly the same as the result of the function (String number Boolean does not have such a property as this type of wrapper object)

If the classes provided in the framework also have this nature, it would be a good choice. This is only an example, and if you notice other details and keep the classes in the framework consistent with the native objects, it is very useful for the user.

4. Respect for language and respect for users

The writing framework should respect the dependent language environment, before modifying the original elements should first consider the original rationality, the native environment of any language has been carefully designed, before any modification, should at least consider the points: efficiency, naming norms, necessity, and other functions are not repeated. If you're not paying at least as much work as the language designer, your approach is under consideration.

The authoring framework should also respect the user's habits and impose the author's preferences on the users, not what the framework should do. The framework should ensure that most of the code that runs without a framework can work properly within the framework so that users do not have to modify the original code in order to use your framework.

5. Canonical naming and use of namespaces

Reducing naming pollution will allow your framework to coexist better with other frameworks. Many frameworks use namespaces to manage, which is a good design. Naming should be clear and meaningful English words, as described in the previous 3, in order to maintain consistent with the original object, the naming convention is best to close to the native object, such as the first letter of the class name uppercase, method name with the hump named. Incidentally, the $ in prototype is a very bad design, and it's impossible to imagine that the purpose of the $ is simply to get the user to write a few letters less. This kind of thing should be given to your users for use in local code.

Design what modules a JavaScript framework needs to write