Which modules need to be written to design a JavaScript framework?

Most existing frameworks provide this part of content, and Language extension should be based on ECMAScript.

In this era where js frameworks run around, have you ever considered writing your own framework? The following content may be helpful.

What should a framework contain?

1. Language extension

Most existing frameworks provide this part of content. Language extensions should be based on ECMAScript and should not depend on any host environment. That is to say, as a framework designer, you should ensure that your language extension can work in any host environment, rather than just applicable to the browser environment. You must ensure that it works correctly in WScript, SpiderMonkey Shell, Rhino Shell, Adobe ExtendScript Toolkit, and even Flash ActionScript environments, for a realistic example, setTimeout cannot appear in it, and you cannot use XMLHTTP to load scripts for running, even though they seem very close to the language. Maintaining the independence of this Part allows you to easily port your framework to other host environments.

2. data structures and algorithms

JS itself provides very limited built-in objects. In many cases, the framework should provide some data structures and algorithms to help users better complete logical expressions. However, I think it is irresponsible to simply flip the data structure or algorithm book and use JS to pick several implementations and add them to the framework. Most data structures should exist in the form of libraries rather than frameworks. The data structure in the framework should be common enough and the implementation is not very complex. You can consider binary searches on collections, hash tables, linked lists, ordered arrays, and ordered arrays. For JS, the Object is a natural string hash table, and the set is easily implemented in the hash table. Therefore, you only need to process the built-in method of the Object, we can implement an efficient set or hash table.

3. DOM Extension

JS is mainly used in Web development. Currently, all the frameworks are also used in the browser environment. The important DOM in the browser environment is also the extension goal of the Framework, if a framework does not provide DOM extensions, it is basically useless. It should be noted that DOM extensions also have w3c standards, so do not try to make some strange extensions for various browsers, such as the prototype of the elements under FF, framework writers should ignore them. One of the main tasks of DOM extension is compatibility. The DOM implementations on different browsers differ a lot. The framework must eliminate these implementations and provide a unified access method. Of course, as a framework, some more convenient interfaces should be provided. It is a good idea to encapsulate the DOM objects provided by the host with js objects, but this may also cause memory leakage, so before doing this, it is necessary to understand the memory leakage. In fact, the extensions you imagine are far inferior to those designed by W3C. For example, if you can implement XPath more completely, you can do better than JQuery.

4. AJAX Extension

Most of the existing frameworks are caused by AJAX, so if you want to design a popular framework, AJAX must be done. Similar to DOM extensions, the main tasks of AJAX extensions are compatibility and Memory leakage. For the XMLHttpRequest object, which is the core component of AJAX, must be created using ActiveX in IE6, and ActiveX has various versions, the memory leakage and compatibility subsequently become very troublesome. For example, the event function name is case-sensitive, this point, and the null value assignment of the event function. Based on the compatibility, we can further work and provide some common implementations. It should be noted that, unless you are sure that the interface you provide is better than the original interface, do not change the interface of the original XMLHttpRequest object, such as writing a Request function to replace open and send, if you don't know why W3C experts are doing this, don't think of them as dummies. I want to add a compatible and memory-safe XMLHttpRequest to the namespace of my framework so that it looks exactly the same as the XMLHttpRequest described by W3C, for XMLHttpRequest, I think the only change that can be considered is to provide an onsuccess event. Of course, AJAX extensions for some complex functions are also feasible. For example, extensions similar to HTMLHttpRequest can make AJAX beginners like your framework.

5. Results

The time effect is the most irritating to the user's nerves. Fading, easing, sliding, and color gradient are all very good. In fact, the technical difficulty is not very high. The drag effect is a very important effect in the browser. It is easy to simulate it with mouse events. However, compatibility and setCapture are also very troublesome. This part of content is sufficient.

6. Script Management

Many frameworks provide AJAX-Based Script management because they like C ++-style include or JAVA-style import very much. However, the efficiency of synchronous loading is huge. We have made various attempts before, hoping to find a method to load external js without XMLHTTP in a browser, but the final conclusion is: it is impossible to think about this, java C ++ C # Is a compilation language, and include and import are both in the compilation phase. It is impossible to do similar things in js. To implement similar functions, I think we can use a server program or write a text tool. YUI extracts Dependencies from all js files. However, this is not an implementation method of include. Maintaining dependency is not very simple.

7. Controls

The success of EXT tells us that the provision of high-quality controls is the king of the framework. You cannot expect high-quality extensions to attract more users. Most people only care about how to quickly complete the work at hand. Of course, not all frameworks need to provide this part. The control quality depends on the ability and beauty, but at least ensure that the control in the framework will not leak memory.

Framework Design Principles

1. Do not do anything extra

For this framework design, I think a very necessary principle is not to do anything redundant. For example:

function add(a,b){　　return a+b;}

Such code is a joke if it appears in the framework. 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 (which is explicitly indicated in ECMA262, unlike some people who say it is based on object cloud), some syntaxes are different from those in Java and other languages. Obviously, the "Implementation" of these OOP is the same as the above example. Another example is Array. prototype. clone:

Array.prototype.clone=function(){return this.slice();}

2. Use prototype extension with caution

Many frameworks use prototype modification of native objects for Language extension, but I think we should be careful with this, without a doubt this will cause some naming pollution, you cannot guarantee that users of the framework or other frameworks that coexist with your framework will not use the same name to complete other things. Note that prototype extensions of objects and arrays are extremely dangerous. For objects, if an Object is modified, users of the framework cannot create an unmodified clean object, which is a fatal problem, especially if your users prefer to use for in to reflect the attributes of an object. Array. the danger of prototype modification comes from a small js design that does not know whether to intentionally or unintentionally. for native arrays, The traversal results of for and for in are the same under any circumstances, however, since custom attributes cannot be controlled, they cannot be enumerated. Any Array. modifications to prototype will destroy this feature. On the one hand, I don't think we should recommend that you use for in to traverse arrays, which contains incorrect semantics. On the other hand, framework designers must respect these users, because the syntax defined by ECMA is correct. It contains the simple fact that, if Array. prototype is modified in your framework, some code that previously worked correctly becomes not working correctly. Directly modifying prototype looks attractive, but two possible solutions should be considered before considering it:

Function: provides a function with the object as the first parameter, such as Array. prototype. each =>

function ForEach(arr,f){if(arr instanceof Array)/*...*/;}

Inheritance: inherit a built-in object in the form of return, for example, consider Array. prototype. each =>

function ArrayCollection()　{var r=Array.apply(this,arguments);　r.each=function(){/*......*/};　　return r;}

Do not modify the prototype of the native object unless you think it is necessary. However, the prototype of the native object does have some special purposes (that is, the "necessary situation"), mainly reflected in 2 points: Support for text volumes and chained expressions. The following two points can be illustrated in an example:

var cf=function f(a,b,c,d){/*........*/}.$curry(3,4).$curry(5).$run();

If you want to implement a similar expression, you may need to extend Function. prototype. If you consider the cost of naming pollution as worthwhile, it can also be provided to users.

A clever way is to give the right of choice to the user and provide an extender:

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

If you like FunctionExtend. apply (Function. prototype); if you do not like extension, you can

var r=function(){/*......*/};FunctionExtend.apply(r);

3. Maintain consistency with native objects

I wonder whether you have noticed that the built-in Object Function Array and so on all have such properties: the results of new Function () are exactly the same as those of Function (encapsulation objects such as String Number Boolean do not have such properties)

If the classes provided in the framework also have this property, it will be a good choice. This is just an example. If you notice other details and keep the classes in the framework consistent with the native objects, It is very beneficial for users.

4. Respect for language and respect for users

The compiling framework should respect the dependent language environment. before modifying the original elements, we should first consider the original rationality. The native environment of any language is carefully designed, before any modification, consider at least these points: efficiency, naming conventions, necessity, and whether they are repeated with other functions. If you have not paid at least the same amount of work as the language designer, your approach is not considered.

Compiling a framework should also respect all users' habits and impose the preferences of writers on users, which is not what the framework should do. The framework should ensure that most of the code that can run without a framework environment can work normally under the framework, so that users do not have to modify the original code to use your framework.

5. Naming and using namespaces

Reducing naming pollution can make your framework better coexist with other frameworks. Many frameworks use namespaces for management, which is well designed. Naming should be clear and practical English words. As described in the previous 3, to maintain consistency with native objects, it is best to keep naming rules close to native objects, such as the first letter of a class name in uppercase, the method name is named in the hump. The $ in prototype is a very bad design. You cannot imagine that $ is only used to allow users to write less letters. This should be handed over to your users for use in local code.

This article is available at http://www.nowamagic.net/librarys/veda/detail/1426.