On the front-end engineering, modular, component-based

What is the front-end engineering, modular, component-based?

Front-end engineering

Engineering is an idea rather than a technical (engineering course in order to achieve that we will use some technology)

Then a common expression to sum up the front end engineering: front-end engineering of the project is to use thinking to do to look and develop their own projects, rather than directly to roll up its sleeves and write a page a page open

Front-end modular
front-end engineering is a high level of thought, and modular and component engineering for the next idea is relatively specific development mode, so you can simply think that is modular and componentized form of engineered.

Modular development, a module is a file specific functions are implemented, with the module we can be more convenient to use someone else's code, what features you use what modules to load.

Modular 4-point advantage development:

　　1 variable avoid contamination, naming conflicts

　　2 to improve the rate of code reuse

　　3 to improve maintenance

　　Management 4 dependencies

It specifically what it is modular? Or give a simple example, we write a realization of JS code A function of this feature in the project also need to use a different location, then we can put this feature as a module using modular write a certain way, both achieve multiplexing can also divide and conquer, empathy when writing style, if we need a particular style, will be applied in many places, so we have a certain way can also be carried out using a modular CSS, specifically, JS module many schemes have AMD / CommonJS / UMD / ES6 Module, etc., CSS modular development are mostly realized under import / mixin feature support less, sass, stylus, etc. preprocessor

Overall, modular Understandably, the focus is to learn the relevant technology and flexible use.

 

Front-end components of the
manifestation of the component is engineered.

① each individual, visual / interactive area on the page as a component;
② Each component corresponds to a project directory, all kinds of resources needed to maintain the components are nearby in this directory;
③ due to component independence and therefore can be freely combined between the component and assembly;
④ page just a container assembly, the combination of components responsible for the formation of a fully functional interface;
⑤ when a component is not required when, or want to replace components, you can delete the entire directory / replace .

The assembly of the page as a container, for example, a page individual parts: head, navigation, focus map, sidebar, bottom, as separate components, according to need different page content, to related components to bloom form a complete page.

: PS under a modular and component most immediate benefit is reuse, but we should also have an idea, modular and component reuse than there is in addition to divide and conquer, we can not affect other code cases modify demand a separate module or component, so many places that we can not have a strong need for multiplexing can also be modular or component-based development according to the needs of divide and conquer.

 

Modular Specification

CommonJS: CommonJS carried forward by the nodeJS, which marks the official debut of modular js.

A definition module

The commonJS specification, a separate file is a module, each module is a single scope, i.e., a variable defined in the interior of the module, function, class, are private, not visible to other documents, It can not be read by other modules except for the global object's properties.

Two output module 

Module is only one exit, module.exports objects, we need to hope that the contents of the output of the module into the object.

Three load modules

Require loading module, the method reads a file and executed, returns the internal module.exports file objects.

var name = 'Byron';  
  
function printName(){  
    console.log(name);  
}  
  
function printFullName(firstName){  
    console.log(firstName + name);  
}  
  
module.exports = {  
    printName: printName,  
    printFullName: printFullName  

然后加载模块

var nameModule = require('./myModel.js');
nameModule.printName();

 

AMD：Asynchronous Module Definition 中文名是一步模块

它是一个在浏览器端模块化开发的规范，由于不是js原生支持，使用AMD规范进行页面开发需要用到对应的函数库，也就是大名鼎鼎的RequireJS，实际上AMD是RequireJS在推广过程中对模块定义的规范化的产出。

requireJS主要解决两个问题：

1 多个js文件可能有依赖关系，被依赖的文件需要早于依赖它的文件加载到浏览器。

2 js加载的时候浏览器会停止页面渲染，加载文件愈多，页面失去响应的时间愈长。

//定义模块

define(['dependency'],function(){
  
  var name = 'Byron';
  function printName(){
     console.log(name);
}
  
  return {
     printName:printName
   }

})

//加载模块

require(['myModule'],function(my){
   my.printName();
})

 

语法：

requireJS定义了一个函数define，它是全局变量，用来定义模块。

define(id,dependencies,factory)

——id  可选参数，用来定义模块的标识，如果没有提供该参数，脚本文件名（去掉拓展名）

——dependencies  是一个当前模块用来的模块名称数组

——factory 工厂方法，模块初始化要执行的函数或对象，如果为函数，它应该只被执行一次，如果是对象，此对象应该为模块的输出值。

 

在页面上使用require函数加载模块；
require([dependencies], function(){});
require()函数接受两个参数：
——第一个参数是一个数组，表示所依赖的模块；
——第二个参数是一个回调函数，当前面指定的模块都加载成功后，它将被调用。加载的模块会以参数形式传入该函数，从而在回调函数内部就可以使用这些模块

 

AMD推崇的是依赖前置，被提前罗列出来并会背提前下载并执行，后来做了改进，可以不用罗列依赖模块，允许在回调函数中就近使用require引入并下载执行模块。

 

 

CMD：即common module definition

就像AMD有个requireJS,CMD有个浏览器实现的sea.js，sj要解决的问题和rj一样，只不过在模块定义方式和模块加载时机上有所不同。

cmd是sea.js在推广过程中的规范化产出，sea.js是另一种前端模块化工具，它的出现缓解了requireJS的几个痛点。

define(id, deps, factory)

因为CMD推崇一个文件一个模块，所以经常就用文件名作为模块id；
CMD推崇依赖就近，所以一般不在define的参数中写依赖，而是在factory中写。

factory有三个参数：
function(require, exports, module){}

一，require
require 是 factory 函数的第一个参数，require 是一个方法，接受 模块标识 作为唯一参数，用来获取其他模块提供的接口；

二，exports
exports 是一个对象，用来向外提供模块接口；

三，module
module 是一个对象，上面存储了与当前模块相关联的一些属性和方法。

demo
// 定义模块  myModule.js
define(function(require, exports, module) {
  var $ = require('jquery.js')
  $('div').addClass('active');
});

// 加载模块
seajs.use(['myModule.js'], function(my){

});

 

AMD与CMD区别

总结如下：

最明显的区别就是在模块定义时对依赖的处理不同。

AMD推崇依赖前置 在定义模块的时候就有声明其依赖的模块

CMD推崇就近依赖 只有在用到某模块的时候再去require

 

AMD和CMD最大的区别是对依赖模块的执行时机处理不同，注意不是加载的时机或者方式不同。

为什么我们说两个的区别是依赖模块执行时机不同，为什么很多人认为ADM是异步的，CMD是同步的（除了名字的原因。。。）
同样都是异步加载模块，AMD在加载模块完成后就会执行改模块，所有模块都加载执行完后会进入require的回调函数，执行主逻辑，这样的效果就是依赖模块的执行顺序和书写顺序不一定一致，看网络速度，哪个先下载下来，哪个先执行，但是主逻辑一定在所有依赖加载完成后才执行。
CMD加载完某个依赖模块后并不执行，只是下载而已，在所有依赖模块加载完成后进入主逻辑，遇到require语句的时候才执行对应的模块，这样模块的执行顺序和书写顺序是完全一致的。
这也是很多人说AMD用户体验好，因为没有延迟，依赖模块提前执行了，CMD性能好，因为只有用户需要的时候才执行的原因。

• 目录结构的制定

-- src                        # 源码目录
   |__ index.js               # 项目入口，注入store, 调用render方法
   |__ App.js       # 应用入口，页面整体布局，处理页面路由 |__ App.less # 全局共用样式文件 |__ theme.less # 项目主题文件 |__ Components |__ ActiveChart # [组件ActiveChart ] |__ index.js # 组件实现源码文件 |__ index.less |__ AxisTitle # [组件AxisTitle] |__ index.js # 组件实现源码文件 |__ index.less |__ routes 定义应用的页面容器组件 |__ Cockpit # [页面1] |__ index.js # 页面具体业务代码 |__ indes.less |__components 页面的私有组件 |__ WorkSpace # [页面2] |__ index.js # 页面具体业务代码 |__ indes.less |__models |__ index.js # 导出封装后的所有store，以及初始化saga |__ request.js # 封装网络请求，比如所所有的方法进行拦截（inspector） |__ model1 # [模块1]store基于具体业务模块来编写，方便多页面调用 |__ actionTypes.js |__ actions.js |__ reducer.js 封装业务逻辑 |__ model2 # [模块2] |__services |__model1.js 封装接口请求 |__model2.js 封装接口请求 |__common 公用的工具库 |__chartUtil |__arrayUtil |__constants