フロントエンドエンジニアリング、モジュラー、コンポーネントベースは何ですか？

フロントエンドエンジニアリング

エンジニアリングのアイデアではなく、技術的な（私たちはいくつかの技術を使用することを達成するために工学コース）であります

そして、一般的な表現は、フロントエンドエンジニアリングを総括するには：プロジェクトのフロントエンドエンジニアリングが見て、直接その袖をロールアップするのではなく、自分のプロジェクトを開発し、ページに開いているページを書くために行うために思考を使用することです

フロントエンドモジュール式の
フロントエンドエンジニアリングは、思考のハイレベルであり、そしてあなたは、単にそれが設計のモジュラーおよびコンポーネント化であると考えることができるように、次のアイデアのためのモジュールおよびコンポーネント技術は、比較的特異的開発モードです。

モジュラー開発は、モジュールは、モジュールで、我々はあなたがロードするモジュールものを使用していますどのように、誰かの他の人のコードを使用する方が便利なことができ、特定の機能が実装されているファイルです。

モジュラー4点のアドバンテージ開発：

　　1つの変数は、名前の競合を、汚染を避けるため

　　2コードの再利用率を向上させます

　　3メンテナンスを向上させるために

　　管理4つの依存関係

それは具体的には、モジュラー何ですか？または簡単な例を与える、我々はまた、両方の、そして私たちは、モジュール式のライトに特定の方法を使用してモジュールとして、この機能を置くことができ、別の場所を使用する必要があるプロジェクトでは、この機能の機能JSコードの実現を書きます多重化はまた、具体的には、JSモジュール、スタイルを書くときに、我々は特定のスタイルが必要な場合は、多くの場所で適用されますので、我々は特定の方法はまた、モジュラーCSSを用いて行うことができている分割し、征服、共感することができます達成多くのスキームは、AMD / CommonJS / UMD / ES6モジュールなど、CSSのモジュラー開発は、主にインポート/ミックスイン機能サポート少なく、SASS、スタイラスなどのプリプロセッサの下で実現されてい

全体的に、モジュラーは当然のことながら、焦点は、関連する技術と柔軟な使用を学ぶことです。

フロントエンドコンポーネント
部品の症状が設計されています。

①個々の成分としてページ上/ビジュアル・インタラクティブ領域は、
②各コンポーネントは、コンポーネントを維持するために必要なリソースのすべての種類は、このディレクトリに近くにあり、プロジェクトディレクトリに対応します。
③によるコンポーネントの独立にそのため、自由に部品とアセンブリの間で組み合わせることができます。
④ちょうど容器アセンブリページ、完全に機能界面の形成を担当するコンポーネントの組み合わせを、
⑤の部品を交換したい場合、またはコンポーネントを必要としない場合、あなたはディレクトリ全体を削除することができます/置き換えます。

開花に関連する成分にヘッド、ナビゲーション、フォーカスマップ、サイドバー、底面、別々の構成要素として、異なるページコンテンツを必要に応じて、例えば：容器、ページの個別部品としてページの組み立て完全なページを形成します。

：PS最も直接的モジュラーおよびコンポーネントの利益の下では再利用ですが、分割し、征服する以外にありよりも、我々はまた、我々は他のコード例に影響を与えることができない、という考え、モジュラーおよびコンポーネントの再利用を持っている必要があります需要に我々はまた、分割統治のニーズに応じてモジュラーまたはコンポーネントベース開発することができ、多重化のための強い必要性を持つことはできません別のモジュールまたはコンポーネントなので、多くの場所を変更します。

モジュラー仕様

CommonJS：モジュラーJSの公式デビューをマークしnodeJS、により繰越CommonJS。

定義モジュール

commonJS仕様、別のファイルがモジュールであり、各モジュールは、単一の範囲、即ち、モジュールの内部で定義された変数、関数、クラスであり、他の文書に見え、プライベートではありません、それはグローバルオブジェクトのプロパティを除き、他のモジュールで読み取ることができません。

二つの出力モジュール

モジュールは1つの出口だけ、module.exportsはオブジェクトである、我々は、オブジェクトへのモジュールの出力の内容ことを期待する必要があります。

三つのロードモジュール

ローディングモジュールを必要とし、この方法は、ファイルを読み取り、実行、内部module.exportsはファイルオブジェクトを返します。

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

フロントエンドエンジニアリングに、モジュラー、コンポーネントベース

フロントエンドエンジニアリング、モジュラー、コンポーネントベースは何ですか？

おすすめ