The value of front-end modular development

This article was published in the March 2013 issue of Programmers magazine and is recommended for purchase.

The value of front-end modular development

With the rapid development of the Internet, front-end development is more and more complex. This article will start with the problems encountered in the actual project, and tell me about the problems that can be solved by modularization, and how to use sea.js for the modularization development of the front end.

Annoying naming conflicts

We start with a simple habit. When I do projects, I often abstract some common, low-level functions into functions, such as

function Each (arr) {  //  Implementation code }function  log (str) {  // implementation Code }

and smarty pants These functions uniformly in the util.js. When needed, the file is introduced. It all worked well and my colleagues thanked me for providing such a handy kit.

It was not until the team grew bigger that people started complaining.

Xiao Yang: I want to define a each method to traverse the object, but the page header of the util.js has already defined A, I can only call eachobject, good helpless.

Xiao Gao: I have customized a log method, why the code written by Xiao Ming is a problem? Somebody help me.

Complaining more and more. After a heated discussion, the team decided to refer to the Java approach and introduce a namespace to solve. So the code in Util.js became

var org == =function  (arr) {  //  Implementation code  function  (str) {  //  implementation code };

Don't assume that the code above is intentionally fabricated to write this article. Build the concept of namespaces in the front-end and push Yahoo! 's YUI2 project. Here is a real code from an open source project from Yahoo!.

if (org.cometd.Utils.isString (response)) {  return  Org.cometd.JSON.fromJSON (response);} if (Org.cometd.Utils.isArray (response)) {  return  response;}

Through namespaces, it is true that conflicts can be greatly mitigated. But often see the above code, can not help but full of sympathy. In order to invoke a simple method, it is necessary to remember such a long namespace, which increases the memory burden while depriving a lot of coding fun.

As the front-end industry benchmark, the YUI team is determined to solve this problem. In the YUI3 project, a new namespace mechanism was introduced.

function (y) {  //  Node module is loaded  /// The following can be called by Y to call  var foo = Y.one ( ' #foo ');});

YUI3 is a good solution to the problem of long namespaces through the sandbox mechanism. However, new problems have also been brought about.

function (Y) {  y.foo ();   // is the Foo method provided by module A or B?     How do I avoid collisions if modules A and B both provide the Foo method? });

Seemingly simple naming conflicts, it is not easy to actually solve them. How to solve it more gracefully? Let's take a look at the other FAQs first.

Cumbersome file-dependent

Continue with the above story. Based on Util.js, I started developing a common component of the UI layer so that project team colleagues wouldn't have to reinvent the wheel.

One of the most popular components is Dialog.js, which is easy to use.

<script src= "Util.js" ></script><script src= "dialog.js" ></script><script>   /**/ }); </script>

However, no matter how I write the document, and how solemnly e-mail announcement, from time to time there will always be colleagues to ask why dialog.js problems. Through some troubleshooting, we find that the cause of the error is often

<script src= "Dialog.js" ></script><script>  /** *  }); </script>

Util.js was not introduced before Dialog.js, so Dialog.js did not work properly. Also do not think that my above story is fictitious, in the company that I have been in, still have similar foot this newspaper wrong, especially in a variety of Quick production marketing page.

The above file dependencies are still within the control range. As projects become more complex, the dependencies between many files can often be maddening. The following questions, I believe, happen every day in a real way.

1. Universal group updated the front-end base class library, but it is difficult to promote the whole station upgrade.
2. The business group wanted to use a new generic component, but found it couldn't be done simply by a few lines of code.
3. A new feature for an old product, the final evaluation can only be based on the old class library to continue to develop.
4. Company integration Business, a certain two product lines to be merged. The results found a front-end code conflict.
5. ......

Many of these problems are due to the fact that file dependencies are not well managed. In the front page, most of the script's dependencies are still guaranteed by human flesh. When the team compares hours, there's no problem. When the team is getting bigger and the business is getting more and more complex, the dependency problem will become a big problem if not solved.

file dependencies, currently in the vast majority of class library framework, such as foreign YUI3 framework, the domestic Kissy and other class libraries, is now through the configuration of the way to solve.

function (Y) {  //  ...}, ' 0.0.1 ', {    requires: [' node ', ' event ']});

The above code requires specifies the dependencies of the current module, in other ways. This can largely solve the dependency problem, but it's not elegant enough. When the module is many, the dependence is very complex, cumbersome configuration will bring a lot of hidden trouble.

Naming conflicts and file dependencies are two classic issues in the front-end development process. Let's see how we can solve this through modular development. To facilitate the description, we use sea.js as a modular development framework.

Use Sea.js to solve

Sea.js is a mature open source project with the core goal of providing a simple, ultimate modular development experience for front-end development. Here is not much to do with the introduction, interested can visit seajs.org to view official documents.

With Sea.js, the CMD (Common module definition) Module definitions specification is required when writing files. A file is a module. The util.js in the previous example becomes

Define (function(require, exports) {  function  (arr) {    //  Implementation code   };   function (str) {    //  Implementation code   };});

exportsinterfaces can be provided outward through. In this way, the Dialog.js code becomes

Define (function(require, exports) {  var util = require ('./util.js ');   function () {    //  Implement code   };});

The key part is here! We require(‘./util.js‘) can get through exports the exposed interface through the util.js. The require here can be thought of as a syntax keyword added to the JavaScript language by Sea.js, which can be used to require obtain interfaces provided by other modules.

It's not really magical at all. As a front-end engineer, you must be familiar with CSS code.

@import url ("base.css"); #id {...}. class {...}

Sea.js added require syntax keywords, as in the CSS file @import , gives our source code to rely on the introduction function.

If you are a back-end development engineer, not unfamiliar. Java, Python, C # and so on, all have include , and import so on. The JavaScript language itself has similar functionality, but is still in the draft phase and needs to wait until the ES6 standard is supported by the mainstream browser.

This makes it very easy to use dialog.js in a page.

<script src= "Sea.js" ></script><script>seajs.use (function(Dialog) {  Dialog.init (/**/);}); </script>

The first is to introduce the Sea.js file in the page, which is generally controlled through the page header, and also facilitates the maintenance of updates. When you want to use a component in a page, simply call through the seajs.use method.

Think about the above code, I believe you have seen the two major benefits of Sea.js:

1. by exports exposing the interface . This means that no namespaces are required, and global variables are not required. This is a thorough naming conflict solution.

2. by require introducing dependencies . This allows for built-in dependencies, developers only need to be concerned about the current module dependencies, and other things sea.js will be handled automatically. For module developers, this is a good separation of concerns , allowing programmers to enjoy coding more.

Summary

In addition to resolving naming conflicts and dependency management, using sea.js for modular development can also provide many benefits:

1. version management of the module . With the configuration of aliases, it is easy to implement the version management of the module with the build tool.

2. improve maintainability . Modularity allows each file to have a single responsibility and is very useful for code maintenance. Sea.js also provides NoCache, debug and other plug-ins, with on-line debugging and other functions, can be more obvious to improve efficiency.

3. front-end performance optimization . Sea.js is useful for page performance by loading modules asynchronously. Sea.js also provides combo, flush and other plug-ins, with the service side, can be good for page performance tuning.

4. share modules across environments . The CMD module definition specification is very similar to node. JS's module specification. With the Sea.js node. js version, it is easy to implement modules across server and browser sharing.

Modular development is not new, but in the WEB domain, front-end development is a freshman post, has been in a relatively primitive era of slash and burn. Until the last two or three years, with the popularization and popularity of Dojo, YUI3, node. JS and other communities, the concept of the front-end modular development was gradually rooted.

The modular construction of the front end can be divided into two main categories. One kind is the cathedral pattern represented by Dojo, YUI3, the kissy of the domestic and so on. In the cathedral mode, all components are granular and modular, and the components are layered and interlocking. Another kind is the market pattern based on jQuery, Requirejs, domestic sea.js, ozjs and other kinds of libraries. In market mode, all components are independent and have a single responsibility, and the components are combined loosely coupled to develop together.

There are application scenarios for these two types of modular construction methods. In the long run, small and beautiful are more tolerant and competitive, more able to form a vibrant ecological circle.

In short, modularity can bring many benefits to front-end development. If you haven't tried it, you might as well start with a trial sea.js.

Finish
Special thanks to this article: http://chaoskeh.com/blog/why-seajs.html
Part of the content is referenced.

Original address: https://github.com/seajs/seajs/issues/547

The value of front-end modular development