I believe that every front-end engineer has his or her favorite JavaScript framework, whether it is emotion or belief. JavaScript framework brings not only convenient development, but also a pure logical beauty, whether it is the graceful simplicity of jquery, Or Yui’s magical sandbox, they all give us endless imagination. However, the js framework is bound to be unable to achieve all-round perfection. For example, jquery 's concessions in OO and yui's sacrifices in performance all convey a kind of imperfect beauty and an ideal realism to people. Today, let’s take a look at these sacrifices and concessions made by yui3 in the framework design, so that we can have a deeper understanding of the full picture of yui3 and maximize its advantages.
1. One step or granulation of seeds
The so-called one-step seeding means that you only need to introduce a script tag of a seed file on the page, such as prototype and jquery, and just introduce a prototype.js or jquery.js. They will encapsulate DOM operations and events, etc. into a file and try to keep it as small as possible. The benefits of doing so are obvious. Using the framework is very simple. However, Yui has divided these functions into levels and granular designs, conceptually abstracting out "core", "tools" and "components". Each small function is placed in a file. When needed, You have to cite it yourself. A large number of demos given in the yui documentation adopt this method. This design is obviously not as friendly to beginners as jquery, and it is not stupid enough to use. In order to implement a small function, it is even necessary to introduce three or four js file. There are two reasons for yui to do this. First, yui is too big, and it is a bit unreliable to put all functions into one file. Second, it pave the way for its dynamically loaded framework design.
2. Manual introduction or dynamic loading
The traditional method of writing js into the page is to directly write the js file in the page as the script tag path. You can also introduce the page in this way using yui, but yui recommends using loader for dynamic loading. The origin of dynamically loaded scripts is very complicated. At present, there are three main reasons. First, the handwritten js tags in the page will occupy an http request anyway. Even if the request is a 304, there is no need to initiate a real http request after the dynamically loaded file is cached. Request, secondly, dynamic loading can realize on-demand loading, and can be based on js files. Deduplication and sorting of interdependencies, loading js files with handwritten tags requires developers to pay extra attention to the sorting, duplication, etc. of files. Thirdly, dynamic loading is conducive to the semantics of page code, which makes developers only care about "What you need", rather than "how to get it". When projects become more bloated and maintenance costs become higher and higher, these small and medium-sized techniques will be of great benefit.
3. Single entrance or sandbox for logical startup
When we start a js logic in a page, we usually put it in a method like onDomReady. What if there are multiple logics in the page? For example, a implements logic A, and the page code is like this
<script src="logicA.js" />
<script>
$.onDomReady(function(){
___LogicA.start();
});
</script>
This code is usually written at the end of the page. The html code accompanying this logic is buried somewhere on the page. At this time, b needs to add logic B to the page. What b does is to first find this code at the end, and then Change it to look like this:
<script src="logicA.js" />
<script src="logicB.js" />
<script>
$.onDomReady(function(){
___LogicA.start();
___LogicB.start();
});
</script>
Similarly, the html code accompanying the B logic is also buried somewhere on the page. It seems that the js logic and its accompanying html code are so separated that when it comes to deleting the function, the html is often deleted but the js is forgotten. , or deleting js and forgetting to delete html will also be a trouble when reusing the code. Similarly, when debugging, engineers also have to open two windows to focus on js and html respectively, even if the two pieces of code are in the same file. In this case, it is better to write the code like this:
This coding method is exactly what Yui advocates, which is the so-called sandbox. Each logic is contained in a sandbox, and each does its own thing without interfering with each other. When a third party browses the code, they immediately understand that this is an independent functional block, including the typical HTML structure and startup logic js. If they want to reuse, they can just copy the entire block.
<!–A logical html code segment–>
<script src="logicA.js" />
<script>
$.onDomReady(function(){
___LogicA.start();
});
</script>
…
<!–B logical html code segment–>
<script src="logicB.js" />
<script>
$.onDomReady(function(){
___LogicB.start();
});
</script>