Front-end Engineering modularity-Take a PHP project as an example

Implementing a page function always requires JavaScript, CSS, and template three languages to be organized, so what we really need is a modular solution that takes JavaScript, CSS, and template into account.

Performance issues caused by front-end modularity

Many of the mainstream modular solutions support features such as anonymous closures, dependency analysis, and module loading through the JavaScript runtime, such as dependency analysis, which requires a regular match to a module's dependencies at JavaScript runtime. Then follow the chain of dependencies (that is, along the dependency layer declared by the module until there is no dependency) to load all the modules that need to be loaded in order one by one, when the module is a lot of complex dependencies, it can seriously affect the performance of the page.

The great inconvenience of modularity as a packaged deployment

The traditional modular scheme is more concerned with how to split the code, but when we deploy on-line, we need to combine the static resources (packaging), this time will find it difficult, each file can only have one module, because the module uses "anonymous definition", after some research, we will find some solutions , whether it is "combo plug-in" or "flush plug-in", we need to modify the code of the modular call, this is undoubtedly worse, developers need not only in the local development focus on the modular split, in the call also need to focus on a request to load which modules more appropriate, Modularity was originally designed to improve development efficiency and reduce maintenance costs, but we found that such a modular approach did not actually reduce maintenance costs, which in some way made the whole project more complex.

First, let's take a look at how a Web project divides the directory structure through an "all-in-one" modular scheme:

• Site: generally refers to the ability to provide services independently, with a separate two-level domain name of the product line. such as the travel product line or the sub-site of the mega site (lv.baidu.com).
• Subsystem (MODULE): A functional business set with a clearer business logic relationship, usually called a system sub-module, and multiple subsystems constitute a site. The subsystem (module) consists of two types: the common subsystem, which provides a generic module for the specification and reuse of the other business subsystems; Business Subsystem: A subsystem site that divides the site according to business, URI, etc.
• Page: output content with a separate URL, and multiple pages can generally form subsystems.
• Module (widget): can provide functions independently and can be reused modular code, according to the method of reuse divided into Template module, JS module, CSS module three kinds.
• Static resources: Non-modular resource directories, including static resources and other static resources (Favicon,crossdomain.xml, etc.) referenced by template pages.

Front-end Module (widget), is able to provide functional and reusable modular code, according to the method of reuse is divided into Template module, JS module, CSS module three types, CSS components, generally speaking, CSS module is the simplest module, it only involves CSS code and HTML code The JS module is slightly more complex, involving JS code, CSS code and HTML code. In general, the JS component can encapsulate the code of the CSS component, template module, involving the most code, can be integrated processing of HTML, JavaScript, CSS and other modular resources, in general, Template will be the JS resource encapsulated into a private JS module, CSS resources encapsulated into Own private CSS modules. Let us introduce the modular solutions of these modules.

Template module

We can put any reusable template code into a smarty file so that a template module can be defined. The Smarty template in the widget directory (this article only takes the Smarty template as an example) is a template module, such as the widget/nav/directory of the common subsystem

├── nav.css├── nav.js└── nav.tpl

The following NAV.TPL contents are as follows:

<navid= "NAV" class= "navigation"  Role= "navigation" > <ul> <% foreach $data as $doc%> <li class= "active"  > <a href= "#section-{[email protected]}" > <i class= "icon-{$doc. Icon} icon-white" ></i><span>{$doc. Title}</span> </a > </li> <%/foreach%> </ul> </NAV>              

Then, we just need a line of code to call this template module containing smarty, JS, CSS resources,

// 调用模块的路径为 子系统名称:模板在 widget 目录下的路劲{widget name="common:widget/nav/nav.tpl" }

This template module (NAV) directory has the same name as the template JS, CSS files, when the template is performed rendering, these resources will be loaded automatically. As shown above, when defining the template module, you only need to store the JS module that the template relies on, the CSS module in the same directory (the default JavaScript module, CSS module and template module with the same name), the caller calls the template module Just write a single line of code, no need to focus on the static resources that the template module is invoked on, and it will help us automatically handle dependencies and resource loading.

JavaScript Module

We describe how a template module defines, invokes, and processes dependencies, and then let's look at how the JavaScript modules that the template module relies on handle the interaction of the modules. We can put any piece of reusable JavaScript code into a JS file, so it can be defined as a JavaScript type of module, we do not care about "define" closure problem, we can get "CommonJS" the same development experience, the following is NA V.js in the source code.

// common/widget/nav/nav.jsvar $ = require(‘common:widget/jquery/jquery.js‘);exports.init = function() { ...};

We can call the JavaScript type module we need by require, require.async, in any place (including HTML, JavaScript modules), and require provides a synchronous calling method similar to the back-end language , the default required modules are loaded when called, and the solution is responsible for loading the static resources. Require.async provides an asynchronous loading mode, mainly used to meet the "load on demand" scenario, when the Require.async is executed to load the required modules, when the module is loaded back will execute the corresponding callback function, the syntax is as follows:

// 模块名: 文件所在 widget 中路径require.async(["common:widget/menu/menu.js"], function( menu ) { menu.init();});

The general require is used to process the required modules on the first screen of the page, Require.async is used to process the on-demand modules outside the first screen.

CSS Module

In the template module and the JS module corresponding to the same name of the CSS module will automatically add dependencies to the template module, JS module, loading management, the user does not need to display the call to load. So how do you declare a dependency on another CSS module in a CSS module, and we can use the @require field tag in the comment to have the same effect on the content of the HTML style tag,

/** * demo.css * @require reset.css */

Non-modular resources

In the actual development process, there may be some static resources that are not suitable for modularization, so we can still manage and load the static resource management system by declaring the dependency relationship.

{require name="home:static/index/index.css" }

If you can declare a dependency on a non-modular resource on a page by using the syntax above, you can automatically load related resources when the page is run.

Project examples

Let's take a look at a real project, if you are invoking various types of widgets through a page, the first is the directory structure:

├── common│   ├── fis-conf.js│   ├── page│   ├── plugin│   ├── static│   └── widget└── photo    ├── fis-conf.js    ├── output    ├── page    ├── static    test    └── widget

We have two subsystems, a common subsystem (used as a generic), a business subsystem, a page directory to hold pages, a widget directory for all types of modules, static for non-modular storage, and first we look at photo/page/ Index.tpl page of the source code,

{extends file="common/page/layout/layout.tpl"}{block name="main"}    {require name="photo:static/index/index.css"}    {require name="photo:static/index/index.js"}    <button id="btn">Button</button> {script type="text/javascript"} // 同步调用 jquery var $ = require(‘common:widget/jquery/jquery.js‘); $(‘#btn‘).click(function() { // 异步调用 respClick 模块 require.async([‘/widget/ui/respClick/respClick.js‘], function() { respClick.hello(); }); }); {/script} // 调用 renderBox 模块 {widget name="photo:widget/renderBox/renderBox.tpl"}{/block}

The first code is the way to call a non-modular resource, the second is to invoke a JavaScript module in a require way, and the third is to invoke a JavaScript module asynchronously through Require.async, and the last is through the widget syntax to invoke a template module. The source code of the Respclick module is as follows:

exports.hello = function() { alert(‘hello world‘);};

The directory structure of the Renderbox template module is as follows:

└── widget    └── renderBox        ├── renderBox.css        ├── renderBox.js        ├── renderBox.tpl        └── shell.jpeg

Although Renderbox below include Renderbox.js, Renderbox.js, RENDERBOX.TPL and other modules, we call the time only need a line of code on it, do not need to focus on internal dependencies, as well as the initialization of various modules.

FIS Open Source Project front-end engineering modularity: http://fex.baidu.com/blog/2014/03/fis-module/

Front-end Engineering modularity-Take a PHP project as an example